# dumortier-marketing-ai-os-verification-2026-08-12

## Veille

Resoconto di esperienza pubblicato su **LinkedIn Pulse** il **12 agosto 2026** da **Guillaume Dumortier**, nella sua newsletter *Growth Marketing Fit*, con il sottotitolo *« Four layers, a lot of rebuilding, and the failure modes nobody warns you about »*, ~2.500 parole. Il tema: un sistema AI interno costruito **in Claude** per un team marketing di una sessantina di persone — una trentina di **skill** di contenuto e vendita, una dozzina di **moduli source-of-truth**, **sette agenti, sei dei quali esistono solo per verificare il lavoro anziché produrlo**, un **plugin** per chi vive nel terminale, un'**applicazione browser** che porta la stessa conoscenza a tutti gli altri, e un'orchestrazione che concatena tre o quattro asset in un *campaign bundle*. La tesi è posta fin dall'inizio: la qualità di un output AI non si determina al momento della generazione, ma da ciò che il sistema sa prima di iniziare e da ciò che accade alla bozza in seguito — *« The generation step in the middle is the easy part. It's also the only part most teams have built. »* Da qui quattro livelli: **Truth** (quasi nessuno lo costruisce), **Production** (tutti), **Verification** (quasi nessuno), **Internal distribution** (*« where good systems die of neglect »*). Due meccanismi di fallimento sostengono l'articolo. **(A) Il « pass » a mondo chiuso nudo del verificatore**: un fact-checker basato sulla documentazione di prodotto riceve una bozza contenente un'affermazione su un altro prodotto, che le sue fonti non coprivano — restituisce un *« pass »*, non perché l'affermazione fosse vera ma perché nulla la contraddiceva. *« It didn't just miss the error, it certified it. »* Correzione: vietare un verdetto nudo e richiedere che ogni rapporto dichiari la propria **copertura** — quante affermazioni sono state controllate, quante corrispondevano a fonti, quali cadevano fuori dalla sua giurisdizione, quali non erano possedute da nessuna fonte. *« "I can't verify this" became a first-class result. »* **(B) La contraddizione tra asset**: due asset possono essere ciascuno individualmente corretto, ciascuno riconducibile a una fonte reale, e comunque contraddirsi a vicenda — il comunicato stampa indica una data, il post del blog un'altra, entrambi passano, il bundle non può essere pubblicato. *« Per-asset verification can't catch that, by construction. »* Clausola conclusiva dell'articolo: *« The generation is free. The trust is the product. »*

## Titre Article

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

## Date

2026-08-12

## URL

https://www.linkedin.com/pulse/i-built-marketing-ai-operating-system-60-person-team-most-dumortier-3hbnc

## Keywords

Guillaume Dumortier, Growth Marketing Fit, LinkedIn Pulse, marketing AI OS, AI marketing, strumento interno, Claude, skill, plugin, applicazione browser, quattro livelli, livello di verità, livello di verità, source of truth, proprietario del documento, versionamento, provenienza, livello di produzione, livello di verifica, distribuzione interna, adozione interna, macchina della fiducia, drift dei fatti, separazione fatti/contenuto, routing delle skill, confini delle skill, contratto di output, ambiguità, scaletta invece di articolo, revisione vuota, approvazione automatica, riciclaggio dell'output, sessione nuova, mondo chiuso, mondo chiuso, dichiarazione di copertura, divieto del pass nudo, affermazione non verificabile, risultato di prima classe, campaign bundle, verifica incrociata tra asset, coerenza incrociata, contraddizione tra asset, revisione che non blocca mai, due interfacce, l'adozione segue la fiducia, incertezza visibile, controllo deterministico, applicazione nel codice, trattino lungo, chiedere gentilmente non è un controllo, fallimento silenzioso, costante vuota, rimozione dei numeri, allucinazione mal attribuita, test della pipeline, lacuna di validazione, rifiuto, insegnare al sistema a rifiutare, costo della verifica, obsolescenza, proprietà e provenienza

## Authors

**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.

## Ton

**Profilo**: resoconto di esperienza ingegneristica interna, in prima persona, pubblicato come newsletter LinkedIn. Pubblico delimitato fin dall'introduzione: *« This is not a piece about whether AI can write well. If that's still the open question for you, this won't land. It's for people already three months in, quietly wondering why the thing works beautifully in demo and keeps producing outputs nobody trusts enough to ship. »* Registro da praticante anti-demo, asciutto, senza vocabolario da venditore.

**Stile**: la struttura è fissa e ripetuta per ciascun livello — sei titoli nello stesso ordine, quattro volte: *What it is* → *Why nobody builds it* → *What I got wrong* → *The rule* → *How you'll know it's working* → *Do this week*. È un modello di audit applicabile al proprio sistema. I criteri di successo sono formulati come segnali osservabili piuttosto che metriche: *« Someone asks "where did this number come from" and the answer takes four seconds instead of an archaeological dig through Slack »*, *« people stop asking you which tool to use for what »*. Il testo non prescrive mai senza prima raccontare il fallimento corrispondente, ammesso nei minimi dettagli ridicoli — le lettere maiuscole nel prompt (*« which is roughly the point you should start suspecting you have the wrong model of the problem »*), la skill del blog che descriveva articoli invece di scriverli, *« every single time »*, per settimane. Ogni sezione si chiude con un aforisma, il che rende il testo facile da citare senza il meccanismo sottostante. La sezione *« what I'm still not sure about »* è collocata prima della conclusione e non viene evitata, con autocritica: *« I currently do a mix and I don't think the mix is reasoned, I think it's a tradeoff I haven't properly examined. »*

**Frasi marcatrici**:
- ***« I was building a trust machine, and I didn't know it »***
- ***« You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible »***
- ***« Nothing that produces content is allowed to contain a fact. It has to ask »***
- ***« a skill's most important job is describing what it is not for »***
- ***« You do not get a bad review. You get a good review that is worthless »***
- ***« It didn't just miss the error, it certified it »***
- ***« An unverifiable claim is a finding, not a silence »***
- ***« If your review step has never blocked anything, it isn't a review step. It's decoration »***
- ***« adoption tracks trust, not capability »***
- ***« Never ask a model for something you can enforce in code »***
- ***« Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality »***
- ***« The generation is free. The trust is the product »***

**Posizione epistemica**: praticante in esercizio, non in dimostrazione. L'articolo non nomina né l'azienda, né i prodotti, né cifre di utilizzo: nessun risultato viene misurato, nessuna adozione quantificata, nessun prima/dopo prodotto — cosa che l'autore dichiara apertamente (*« I'm going to tell you what broke, because the broken parts are the useful part »*). Forte autorità sui meccanismi di fallimento incontrati; nessuna sulla loro frequenza, costo o generalità. Limiti da tenere presenti: n=1, un solo stack, diverse correzioni generalizzate dall'autore senza dimostrazione, e un costo riconosciuto ma non quantificato.

## Pense-betes

- **Data / fonte**: **12 agosto 2026**, LinkedIn Pulse, newsletter *Growth Marketing Fit*, ~2.500 parole. Sistema costruito in **Claude** per un team marketing di ~60 persone.
- **Framing chiave**: *« I thought I was building a content machine. I was building a trust machine, and I didn't know it, so I spent my initial effort in exactly the wrong place. »* ### Vietare il « pass » nudo Un verificatore è un **sistema a mondo chiuso**: può pronunciarsi solo su ciò che gli è stato fornito. Di fronte a un'affermazione che nessuna delle sue fonti copre, non trova contraddizioni e restituisce un verdetto favorevole indistinguibile da un controllo reale. La correzione è un vincolo di formato: | Il rapporto deve dichiarare | Perché | |---|---| | Quante affermazioni sono state **controllate** | denominatore: senza di esso, un « OK » non significa nulla | | Quante sono state **effettivamente ricondotte a una fonte** | è il vero tasso di copertura, sempre più basso | | Quali **cadevano fuori dalla sua giurisdizione** | altrimenti il giudice va oltre il suo mandato e il silenzio su altre affermazioni passa per accordo | | Quali **non sono possedute da nessuna fonte nel sistema** | è il vero registro dei rischi dell'organizzazione | *« I can't verify this »* deve essere un risultato di prima classe, sullo stesso piano di « pass » e « fail ». L'anti-pattern simmetrico è più pericoloso dell'assenza totale di controllo: *« a good review that's worthless is far worse than no review, because it launders the output »* — qualcuno a valle vede *reviewed: pass* e smette di controllare. Rimando incrociato a [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### Il controllo che la verifica per singolo asset non può produrre Due asset della stessa campagna possono essere ciascuno individualmente corretto, ciascuno riconducibile a una fonte reale, ciascuno convalidato — e comunque contraddirsi a vicenda. Verificare rispetto al livello di verità e verificare gli asset l'uno contro l'altro sono **due controlli diversi**; il primo non può produrre il secondo. La diagnosi dell'autore: *« if you run multi-asset campaigns and only verify one asset at a time, you have this bug right now. »* Trasposizione fuori dal marketing: una PR che tocca tre file, un insieme di spec generate in batch, un documento e il suo codice prodotti insieme. La coerenza incrociata è un controllo a livello di bundle, mai una somma di controlli unitari. ### Il livello di verità Fallimento raccontato: i fatti di prodotto vivevano **dentro** la skill che scriveva gli articoli, poi lo stesso fatto doveva esistere nella skill email, nella battlecard, nella pagina web. *« Within a few weeks I had four slightly different versions of our launch date in four different files, and the drift was invisible because each file was individually plausible. »* Regola: *« a document that states facts and a document that produces content are two different documents, with two different owners »*, ciascuno versionato e datato. A nulla che produce contenuto è permesso contenere un fatto — deve richiederlo. Beneficio: un fatto cambia, lo si cambia una volta sola, tutte le 35 skill sono corrette il giorno dopo; un'affermazione viene contestata, c'è un solo posto dove guardare. Perché nessuno lo costruisce: *« You cannot demo a truth layer. You can only demo what it prevents, which is nothing visible. »* Esercizio proposto: aprire gli ultimi cinque asset prodotti, evidenziare ogni affermazione fattuale, indicare per ciascuna l'unico documento che la possiede — *« the ones you can't assign an owner to are your real risk register. »* Estende [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Due lezioni sulle skill 1. **Il contratto di output deve essere paranoico riguardo all'ambiguità.** Per settimane, la skill « blog post » ha scritto **descrizioni di articoli** — intestazioni di sezione seguite da una frase che spiegava cosa avrebbe coperto la sezione, *« every single time »* — e ha superato ogni revisione, perché la struttura era impeccabile. Causa: una riga ambigua nel template (*« the post, under the flavour's own section headers »*), letta ragionevolmente come una richiesta di scaletta. Dettaglio organizzativo più importante del bug: nessuno l'ha segnalato, *« people assume the tool is right and they're using it wrong. »* 2. **Il compito più importante di una skill è descrivere a cosa non serve.** Superate circa trenta skill, il problema smette di essere la qualità e diventa il **routing**: due skill che gestiscono entrambe plausibilmente *« write me something for sales »* si contendono ogni richiesta, e il vincitore arbitrario produce il formato sbagliato. Metà di ogni descrizione è diventata un confine esplicito. Confronto con [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Dal prompt all'idraulica Le regole di voce vietavano i trattini lunghi, ogni prompt lo diceva, i tester continuavano a trovarne per settimane: *« I kept repeating the rule louder, which is a probabilistic fix to a problem whose deterministic solution was right there. »* Correzione: un'unica funzione lato output che li rimuove. Euristica generalizzabile: *« if you catch yourself repeating an instruction, that's the signal to pull it out of the prompt and put it in the plumbing »*, con il suo corollario — *« asking nicely is not a control. »* ### Il fallimento silenzioso Una costante destinata a contenere un carattere marcatore invisibile era stata svuotata a stringa vuota. Nessun diff visibile, nessun errore. A valle, una fase di pulizia ha iniziato a intercettare ogni cifra in ogni prompt e a rimuoverla: `« 7.1% across 6,000+ orgs, 2500 words »` raggiungeva il modello come `« .% across ,+ orgs, words »`. Ogni statistica, data, conteggio parole e numero di sezione silenziosamente rimossi, per un numero imprecisato di release. Era questa la vera ragione per cui le cifre citate risultavano sempre sbagliate — *« and I'd spent weeks blaming the model's tendency to make up numbers. It was making them up because I'd deleted them. »* Principio: *« Traditional software crashes when it breaks. These systems keep going, confidently, at reduced quality, and produce something that looks correct. »* Due correzioni: testare **la pipeline**, non solo l'output — un test la cui unica funzione è verificare che i numeri sopravvivano a un round trip attraverso l'assemblaggio del prompt; e ricordare che la validazione ha le stesse lacune del sistema — un campo limitato a 500 caratteri è rimasto a 688 per due release perché lo script controllava ogni altro limite tranne quello. Regola diagnostica: prima di accusare un modello di aver inventato un numero, verificare che il numero lo abbia effettivamente raggiunto. ### Livello 4, distribuzione interna *« This is where most internal AI projects die quietly. Not from technical failure. From being technically excellent and used by four people. »* L'autore aveva costruito prima per sé — un plugin che richiedeva dimestichezza con la riga di comando, il che descriveva sei persone su sessanta. Correzione: lo stesso sistema costruito due volte, stessa conoscenza e stessi controlli, due punti d'accesso — un plugin per chi costruisce, un'applicazione browser per tutti gli altri (catalogo, tre campi, una bozza con i suoi controlli accanto come pulsanti). Il punto più fine della sezione: **l'adozione segue la fiducia, non la capacità**. Lo strumento ha guadagnato uso quando l'output ha iniziato ad ammettere ciò di cui non era sicuro — *« A draft that flags "this customer example is illustrative, find a real one before publishing" gets used. A draft that confidently presents a made-up customer example gets used once, embarrasses someone, and the tool dies by word of mouth. »* ### Insegnare al sistema a rifiutare L'ultimo pezzo adatta un asset per un altro segmento di mercato e conosce il segmento che l'azienda ha deciso di non perseguire: richiesto per quel segmento, rifiuta e spiega perché. *« Same principle as the coverage statement. A system that can only say yes will confidently hand you the wrong thing forever, and you won't be able to tell "this is right" from "this was the only answer available." »* Il rifiuto e l'ammissione di ignoranza sono la stessa primitiva: la capacità del sistema di delimitare il proprio dominio di competenza. ### Le tre incertezze lasciate aperte 1. **Livello di verità integrato o recuperato in tempo reale?** *« Embedded copies go stale without anyone noticing. Live fetches are slow and break when someone renames a folder. »* L'autore usa un mix e dice che non è una scelta ragionata. 2. **Il costo della verifica regge ancora?** Un asset completamente verificato costa *« several times »* una bozza grezza: ne vale la pena per il lavoro rivolto al pubblico, probabilmente no per un riepilogo interno, *« and the line between the two is blurrier than my system claims. »* Variabile di governance da strumentare per prima: un livello di verifica legato alla criticità dell'asset. 3. **Quanto di tutto ciò sopravvive alle prossime due generazioni di modelli?** La sua scommessa, presentata come tale: il livello di verità e la disciplina di copertura sopravvivono, perché *« solve an organizational problem of provenance and ownership that would exist even with a perfect model. »* ### Il piano « se inizi lunedì » 1. Scrivere i **dieci fatti** che il team ripete più spesso, con un proprietario e una data per ciascuno — versione zero del livello di verità, *« it takes an afternoon. »* 2. Prendere il proprio prompt migliore ed estrarne ogni fatto in quel documento; far sì che il prompt li richieda. 3. Costruire una fase di verifica che gira **in una sessione nuova**, vede solo la bozza e le fonti, e deve dichiarare cosa non ha potuto controllare. 4. Individuare ciò che continua a essere ripetuto nei prompt e spostarlo nel codice. 5. Mostrarlo a una persona non tecnica e osservarla usarlo senza aiuto. Test di base da eseguire prima di tutto: far passare un asset **già pubblicato** attraverso il controllo in una sessione completamente nuova, senza altro contesto che la bozza e le fonti. *« What comes back is your real quality baseline. It's usually humbling. Mine was. »*

## RésuméDe400mots

Resoconto di esperienza pubblicato su **LinkedIn Pulse** il **12 agosto 2026** da **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), su un sistema AI marketing interno costruito **in Claude** per un team di una sessantina di persone: una trentina di skill, una dozzina di moduli di verità, **sette agenti, sei dei quali si limitano a verificare il lavoro**, un plugin da terminale, un'applicazione browser e l'orchestrazione multi-asset delle campagne.

**La tesi.** *« I thought I was building a content machine. I was building a trust machine. »* La qualità di un output AI non si determina alla generazione, ma da **ciò che il sistema sa in anticipo** e da **ciò che accade alla bozza in seguito**. La generazione è la parte facile — e l'unica che la maggior parte dei team ha costruito.

**Quattro livelli.** *Truth*: documenti di fatti separati da tutto ciò che produce contenuto, ciascuno con un proprietario, versionato e datato. Lasciare i fatti dentro le skill ha prodotto **quattro versioni di una data di lancio in quattro file diversi**, ciascuna individualmente plausibile. *Production*: la skill del blog ha passato settimane a scrivere **descrizioni di articoli** invece di articoli, superando ogni revisione, perché la revisione controllava la struttura. Oltre le trenta skill, il problema diventa il **routing** — metà di ogni descrizione di skill deve dichiarare a cosa non serve. *Verification*: il livello che separa una demo da un sistema. *Internal distribution*: dove i progetti muoiono per essere eccellenti e usati da quattro persone.

**I due fallimenti centrali.** Un fact-checker riceve un'affermazione che nessuna delle sue fonti copre: restituisce un « pass ». *« It didn't just miss the error, it certified it. »* Correzione: un verificatore è un **sistema a mondo chiuso**; **gli è vietato restituire un « pass » nudo** e deve dichiarare la propria copertura — quante affermazioni controllate, quante effettivamente corrisposte, quali cadevano fuori dalla sua giurisdizione, quali non erano possedute da nessuna fonte. *« An unverifiable claim is a finding, not a silence. »* Secondo fallimento: **due asset individualmente corretti possono contraddirsi a vicenda**; la verifica per singolo asset non può coglierlo, per costruzione.

**Cinque regole trasversali.** Non chiedere mai a un modello qualcosa che si può far rispettare nel codice. I **fallimenti silenziosi** sono l'intero rischio — una costante svuotata ha eliminato ogni numero da ogni prompt, e il colpevole individuato era il modello per aver « allucinato ». Testare la pipeline, non solo l'output. La propria validazione ha le stesse lacune del proprio sistema. **Insegnare al sistema a rifiutare.**

**L'adozione segue la fiducia, non la capacità**: un output che ammette ciò di cui non è sicuro viene usato. Clausola conclusiva: ***« The generation is free. The trust is the product. »***

## GrapheDeConnaissance

- Guillaume Dumortier —a_créé→ Marketing AI OS (TECHNOLOGIE, 0.96)
- Marketing AI OS —utilise→ Claude (TECHNOLOGIE, 0.93)
- Marketing AI OS —est_instance_de→ système interne à quatre couches — vérité, production, vérification, distribution — servant une équipe marketing d'une soixantaine de personnes avec une trentaine de skills, une douzaine de modules de source de vérité et sept agents dont six ne font que contrôler (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ la qualité d'une sortie IA n'est pas déterminée au moment de la génération mais par ce que le système sait avant de commencer et ce qui arrive au brouillon après qu'il a fini (AFFIRMATION, 0.95)
- Guillaume Dumortier —affirme_que→ il croyait construire une machine à contenu alors qu'il construisait une machine à confiance, ce qui lui a fait dépenser son effort initial au mauvais endroit (CITATION, 0.95)
- couche de vérité —fait_partie_de→ Marketing AI OS (TECHNOLOGIE, 0.94)
- couche de vérité —réduit→ la dérive factuelle : un fait modifié une seule fois rend correctes les trente-cinq skills dès le lendemain, et toute affirmation contestée n'a qu'un document propriétaire et qu'une personne à interroger (AFFIRMATION, 0.92)
- Guillaume Dumortier —recommande→ qu'un document qui énonce des faits et un document qui produit du contenu soient deux documents différents avec deux propriétaires différents, rien de ce qui produit du contenu n'ayant le droit de contenir un fait (AFFIRMATION, 0.95)
- vérification en monde clos —s_applique_à→ tout vérificateur automatique adossé à un corpus de sources fini, qui ne peut se prononcer que sur ce qu'on lui a fourni (AFFIRMATION, 0.93)
- vérification en monde clos —observé_dans→ un vérificateur de faits ayant rendu un « pass » sur une affirmation portant sur un produit que ses sources ne couvraient pas : rien ne la contredisait, donc il n'a trouvé aucun problème et a certifié l'erreur au lieu de la manquer (AFFIRMATION, 0.95)
- déclaration de couverture —résout→ la certification en monde clos : le vérificateur ne peut pas renvoyer un « pass » nu et doit énoncer combien d'affirmations il a contrôlées, combien il a réellement appariées à ses sources, lesquelles ne relevaient pas de sa juridiction et lesquelles ne sont possédées par aucune source du système (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ une affirmation invérifiable est un constat et non un silence, « je ne peux pas vérifier ceci » devant être un résultat de première classe (CITATION, 0.95)
- Guillaume Dumortier —affirme_que→ une bonne revue sans valeur est bien pire que pas de revue du tout, parce qu'elle blanchit la sortie et que quelqu'un en aval voit « reviewed: pass » et arrête de regarder (AFFIRMATION, 0.94)
- vérification inter-actifs —résout→ la contradiction entre actifs d'un même lot : deux actifs peuvent être individuellement corrects, traçables vers de vraies sources et validés, tout en se contredisant, ce que la vérification par actif ne peut pas attraper par construction (AFFIRMATION, 0.94)
- Guillaume Dumortier —recommande→ que chaque contrôle tourne comme un appel réellement séparé, sans mémoire de la rédaction du brouillon, différents contrôles possédant des juridictions disjointes et n'ayant pas le droit de noter le terrain des autres (AFFIRMATION, 0.93)
- Guillaume Dumortier —affirme_que→ le travail le plus important d'une skill est de décrire ce à quoi elle ne sert pas, le problème cessant d'être la qualité pour devenir le routage passé une trentaine de skills (AFFIRMATION, 0.94)
- ambiguïté du contrat de sortie —observé_dans→ une skill d'article de blog ayant produit pendant des semaines des descriptions d'articles au lieu d'articles, à cause d'une seule ligne ambiguë du gabarit, et passant toutes les revues parce que la revue contrôlait la structure (AFFIRMATION, 0.93)
- Guillaume Dumortier —recommande→ de ne jamais demander à un modèle ce qu'on peut imposer en code, la répétition d'une instruction dans les prompts étant le signal de la déplacer dans la plomberie — demander gentiment n'est pas un contrôle (CITATION, 0.95)
- échec silencieux —observé_dans→ une constante censée contenir un caractère marqueur invisible vidée en chaîne vide, faisant supprimer par une étape de nettoyage chaque chiffre de chaque prompt pendant un nombre indéterminé de releases, sans diff visible ni erreur (AFFIRMATION, 0.95)
- Guillaume Dumortier —affirme_que→ le logiciel traditionnel plante quand il casse alors que ces systèmes continuent avec assurance à qualité réduite et produisent quelque chose qui a l'air correct (CITATION, 0.94)
- Guillaume Dumortier —recommande→ de tester le pipeline et pas seulement la sortie, par exemple un test dont l'unique fonction est d'affirmer que les chiffres survivent à un aller-retour dans l'assemblage du prompt (AFFIRMATION, 0.93)
- Guillaume Dumortier —affirme_que→ l'adoption suit la confiance et non la capacité : un brouillon qui signale son incertitude est utilisé, un brouillon qui présente avec assurance un exemple inventé est utilisé une fois puis l'outil meurt par le bouche-à-oreille (AFFIRMATION, 0.93)
- Guillaume Dumortier —recommande→ de construire la seconde interface plus tôt que ce qui semble justifié et de rendre l'incertitude du système visible plutôt que de la cacher pour paraître plus impressionnant (AFFIRMATION, 0.92)
- Guillaume Dumortier —recommande→ d'apprendre au système à refuser, une étape déclinant explicitement une demande hors périmètre commercial, parce qu'un système qui ne peut que dire oui tendra avec assurance la mauvaise chose sans qu'on puisse distinguer « c'est juste » de « c'était la seule réponse disponible » (AFFIRMATION, 0.94)
- Guillaume Dumortier —affirme_que→ une étape de revue qui n'a jamais rien bloqué n'est pas une étape de revue mais de la décoration (CITATION, 0.94)
- Guillaume Dumortier —mesure→ un actif entièrement vérifié coûte plusieurs fois le prix d'un brouillon brut, ce qui est justifié pour toute publication publique mais probablement pas pour une synthèse interne (MESURE, 0.85)
- Guillaume Dumortier —prédit→ que la couche de vérité et la discipline de couverture survivront aux deux prochaines générations de modèles, parce qu'elles ne compensent pas un raisonnement faible mais résolvent un problème organisationnel de provenance et de propriété qui existerait même avec un modèle parfait (AFFIRMATION, 0.9)
- Guillaume Dumortier —affirme_que→ la génération est gratuite et que la confiance est le produit (CITATION, 0.96)
- déclaration de couverture —s_applique_à→ tout dispositif de LLM-juge hors marketing, notamment la revue de code automatisée et l'évaluation de sorties générées (AFFIRMATION, 0.85)
- Growth Marketing Fit —publie→ Marketing AI OS (TECHNOLOGIE, 0.85)

---
Canonical: https://www.thekb.eu/it/fiches/dumortier-marketing-ai-os-verification-2026-08-12/