AI governance starts to matter when it leaves the policy document and enters the operating model. Clear ownership. Explicit authority. Defined escalation paths. Data boundaries. Runtime visibility. Production criteria. That is what turns governance from a control layer into an execution capability. Governance creates velocity when it makes boundaries explicit. dataversity.net/articles/to-… #AIGovernance #AgenticAI #EngineeringLeadership #OperatingModel #AILeadership

Responsible AI becomes real when responsibility is executable at runtime. Once agents become non-human identities with permissions, tools and machine-to-machine access, governance can no longer live only in policy. It has to exist in the system: identity, authority, observability, revocation and recovery. You cannot govern what you cannot see — or interrupt. Redefining Corporate Responsibility For The AI-Powered Tech Stack via @forbes forbes.com/councils/forbeste…

NO83 / Decision Note #01 I’m building NO83, an experimental crypto decision system. The goal is not to “predict the market”. It is to answer a harder question: How do you make better decisions when the future remains uncertain? One principle became fundamental very quickly: A winning trade can still be a bad decision. A losing trade can still be a good one. At T0, NO83 only knows: • signals • market context • competing hypotheses • risk The outcome comes later. So the system keeps two things strictly separate: WHAT WE KNEW WHEN WE DECIDED from WHAT HAPPENED AFTER If you judge a decision using information that only existed afterwards, you are not learning. You are rewriting history. Decision quality ≠ outcome quality.

The model predicts. The system has to know what to do when the prediction is wrong.

If robotics benchmarks start getting zero-shot commoditized, the moat moves. From benchmark capability → to real-world robustness. From model performance → to adaptation, verification and recovery. Component performance ≠ system performance.

AI does not fix an ambiguous operating model. It amplifies it. Better models won’t compensate for unclear ownership, slow decision rights or broken handoffs. The real leverage comes from redesigning how decisions, accountability and workflows operate around AI. Governance, done well, creates velocity.

Nous avons construit une application mobile intégrant un modèle IA. Nous cherchons maintenant la bonne personne pour la reprendre. Nous avons conçu et développé Shoot Tracker, une application mobile destinée aux tireurs sportifs, capable de détecter et d’analyser automatiquement les impacts sur cible. Le projet a été construit à deux : expertise métier / usages du tir sportif conception technique, développement mobile, computer vision et pipeline ML de mon côté Le produit permet notamment : • détection des impacts en temps réel sur la cible • analyse d’une photo de cible déjà tirée • correction manuelle des impacts détectés • calcul du scoring • analyse des séquences de tir pour faciliter la correction • gestion complète des séances de tir • historisation des résultats (par arme) • statistiques de performance et de progression Sous le capot, le produit combine : • Flutter / Dart Android • détection d’objets avec TensorFlow • traitement d’image OpenCV / C++ • keypoint matching et homographie • pipeline MLOps en Python pour les datasets, l’entraînement et le versioning des modèles L’application a été testée sur des centaines de cibles réelles, avec une précision de détection comprise aujourd’hui entre 85 % et 95 % selon les conditions de prise de vue. Une boucle complète d’amélioration est déjà en place : les images terrain peuvent être collectées, revues, ajoutées au dataset puis réutilisées pour entraîner de nouvelles versions du modèle. Le produit est fonctionnel. Et nous souhaitons maintenant trouver un entrepreneur, une entreprise ou une équipe produit capable de l’emmener plus loin : optimisation IA, internationalisation et lancement commercial. La reprise peut inclure l’application mobile, le code source, le pipeline ML, les modèles entraînés, les datasets et le savoir-faire technique associé. Si vous connaissez quelqu’un actif dans le tir sportif, la computer vision, les applications mobiles sportives ou l’IA appliquée, nous sommes preneurs d’une mise en relation. Message privé bienvenu. #IA #ComputerVision #MobileApp #MLOps #SportTech

This distinction matters. Predicting future sensory states together with actions moves us from perception toward dynamics: what will happen if the system acts? But prediction is only part of the loop. The architectural challenge is what comes next: predict → act → observe → verify → recover. That is where models become systems.

World models won’t know everything in advance. The challenge is to combine trusted standards with autonomous learning — allowing robots to explore when risk is low, while enforcing verified knowledge and constraints when the physical stakes increase.

The CEO–CTO relationship breaks when technology becomes a translation problem. I have seen the same pattern in very different organizations. The CEO talks about growth, customers, margin and risk. The CTO talks about architecture, technical debt, platforms and engineering capacity. Both may be right. But if they need constant translation to understand each other, the organization has a problem. Because technology decisions are business decisions. A platform migration is not just an architecture topic. It changes cost, risk and execution capacity. Technical debt is not just a code-quality issue. It changes time-to-market and the ability to respond to the business. Cybersecurity is not just an IT concern. It changes operational risk and potentially the value of the company. Engineering capacity is not just headcount. It is a portfolio of investment choices. A strong CEO–CTO relationship therefore does not depend on the CTO making technology “simpler” for the CEO. It depends on both sides using the same decision language: • value • risk • cost • options • trade-offs • time The CTO should understand the business well enough to express technology choices in business terms. And the CEO should understand technology well enough to recognize when a technical constraint has become a strategic constraint. When that happens, technology stops being a translation problem. It becomes part of the company’s operating model. Clarity scales. Talents build.

The first 30 days of a CTO transformation should contain almost no transformation. When you join an engineering organization under pressure, the temptation is strong. Change the structure, the process, the tooling, the roadmap. I have learned to resist that instinct.