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

## Veille

Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier**, en su newsletter *Growth Marketing Fit*, subtitulado *« Cuatro capas, mucha reconstrucción y los modos de fallo de los que nadie te advierte »*, ~2.500 palabras. El tema: un sistema de IA interno construido **en Claude** para un equipo de marketing de unas sesenta personas — alrededor de treinta **skills** de contenido y ventas, una decena de **módulos de fuente de verdad**, **siete agentes, seis de los cuales existen únicamente para verificar el trabajo en lugar de producirlo**, un **plugin** para quienes viven en una terminal, una **aplicación de navegador** que porta el mismo conocimiento para el resto, y una orquestación que encadena tres o cuatro activos en un *campaign bundle*. La tesis se plantea desde el principio: la calidad de una salida de IA no se determina en el momento de la generación, sino por lo que el sistema sabe antes de empezar y por lo que ocurre con el borrador después — *« El paso de generación en el medio es la parte fácil. También es la única parte que la mayoría de los equipos han construido. »* De ahí cuatro capas: **Verdad** (casi nadie la construye), **Producción** (todo el mundo), **Verificación** (casi nadie), **Distribución interna** (*« donde los buenos sistemas mueren por negligencia »*). Dos mecanismos de fallo sostienen el artículo. **(A) El « pass » desnudo de mundo cerrado del verificador**: un fact-checker respaldado por documentación de producto recibe un borrador que contiene una afirmación sobre otro producto, uno que sus fuentes no cubrían — devuelve un *« pass »*, no porque la afirmación fuera cierta sino porque nada la contradecía. *« No solo pasó por alto el error, lo certificó. »* Solución: prohibir un veredicto desnudo y exigir que cada informe declare su **propia cobertura** — cuántas afirmaciones se verificaron, cuántas se relacionaron con fuentes, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« "No puedo verificar esto" se convirtió en un resultado de primera clase. »* **(B) La contradicción entre activos**: dos activos pueden ser individualmente correctos, cada uno trazable a una fuente real, y aun así contradecirse entre sí — el comunicado de prensa indica una fecha, la entrada de blog otra, ambos pasan, el bundle no puede publicarse. *« La verificación por activo individual no puede detectar eso, por construcción. »* Cláusula de cierre del artículo: *« La generación es gratis. La confianza es el producto. »*

## 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, IA de marketing, herramienta interna, Claude, skills, plugin, aplicación de navegador, cuatro capas, capa de verdad, capa de verdad, fuente de verdad, propietario del documento, versionado, procedencia, capa de producción, capa de verificación, distribución interna, adopción interna, máquina de confianza, deriva de hechos, separación hechos/contenido, enrutamiento de skills, límites de skills, contrato de salida, ambigüedad, esquema en lugar de artículo, revisión vacía, sello de goma, blanqueo de salida, sesión nueva, mundo cerrado, mundo cerrado, declaración de cobertura, prohibición del pass desnudo, afirmación no verificable, resultado de primera clase, campaign bundle, verificación entre activos, coherencia cruzada, contradicción entre activos, revisión que nunca bloquea, dos interfaces, la adopción sigue a la confianza, incertidumbre visible, control determinista, imposición en código, raya larga, pedir amablemente no es un control, fallo silencioso, constante vacía, eliminación de números, alucinación mal atribuida, prueba de pipeline, hueco de validación, rechazo, enseñar al sistema a rechazar, coste de verificación, obsolescencia, propiedad y procedencia

## 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

**Perfil**: informe de experiencia de ingeniería interna, en primera persona, publicado como newsletter de LinkedIn. Audiencia delimitada desde la introducción: *« Esto no es un artículo sobre si la IA puede escribir bien. Si esa sigue siendo la pregunta abierta para ti, esto no te va a llegar. Es para gente que ya lleva tres meses, preguntándose en silencio por qué la cosa funciona de maravilla en la demo y sigue produciendo salidas que nadie confía lo suficiente como para publicar. »* Registro de practicante anti-demo, seco, sin vocabulario de vendedor.

**Estilo**: la estructura es fija y se repite para cada capa — seis encabezados en el mismo orden, cuatro veces: *Qué es* → *Por qué nadie lo construye* → *Qué hice mal* → *La regla* → *Cómo sabrás que funciona* → *Haz esto esta semana*. Es una plantilla de auditoría que se puede ejecutar contra el propio sistema. Los criterios de éxito se formulan como señales observables más que como métricas: *« Alguien pregunta "de dónde viene este número" y la respuesta tarda cuatro segundos en lugar de una excavación arqueológica en Slack »*, *« la gente deja de preguntarte qué herramienta usar para qué »*. El texto nunca prescribe sin antes relatar el fallo correspondiente, admitido con detalle ridículo — las mayúsculas en el prompt (*« que es más o menos el punto en el que deberías empezar a sospechar que tienes el modelo equivocado del problema »*), la skill de blog que describía artículos en lugar de escribirlos, *« absolutamente cada vez »*, durante semanas. Cada sección cierra con un aforismo, lo que hace el texto fácil de citar sin el mecanismo subyacente. La sección *« de lo que aún no estoy seguro »* se sitúa antes de la conclusión y no se rehúye, con autocrítica: *« actualmente hago una mezcla y no creo que la mezcla sea razonada, creo que es una compensación que no he examinado adecuadamente. »*

**Frases marcadoras**:
- ***« Estaba construyendo una máquina de confianza, y no lo sabía »***
- ***« No puedes hacer una demo de una capa de verdad. Solo puedes hacer una demo de lo que evita, que no es nada visible »***
- ***« Nada que produzca contenido tiene permitido contener un hecho. Tiene que solicitarlo »***
- ***« el trabajo más importante de una skill es describir para qué no sirve »***
- ***« No obtienes una mala revisión. Obtienes una buena revisión que no vale nada »***
- ***« No solo pasó por alto el error, lo certificó »***
- ***« Una afirmación no verificable es un hallazgo, no un silencio »***
- ***« Si tu paso de revisión nunca ha bloqueado nada, no es un paso de revisión. Es decoración »***
- ***« la adopción sigue a la confianza, no a la capacidad »***
- ***« Nunca le pidas a un modelo algo que puedes imponer en código »***
- ***« El software tradicional se cae cuando se rompe. Estos sistemas siguen funcionando, con confianza, con calidad reducida »***
- ***« La generación es gratis. La confianza es el producto »***

**Posición epistémica**: practicante en operación, no en demostración. El artículo no nombra ni la empresa, ni los productos, ni cifras de uso: no se mide ningún resultado, no se cuantifica ninguna adopción, no se presenta ningún antes/después — algo que el autor reconoce abiertamente (*« voy a contarte lo que se rompió, porque las partes rotas son la parte útil »*). Fuerte autoridad sobre los mecanismos de fallo encontrados; ninguna sobre su frecuencia, coste o generalidad. Límites a tener en cuenta: n=1, una única pila tecnológica, varias soluciones generalizadas por el autor sin demostración, y un coste reconocido pero no cuantificado.

## Pense-betes

- **Fecha / fuente**: **12 de agosto de 2026**, LinkedIn Pulse, newsletter *Growth Marketing Fit*, ~2.500 palabras. Sistema construido en **Claude** para un equipo de marketing de ~60 personas.
- **Enfoque clave**: *« Pensaba que estaba construyendo una máquina de contenido. Estaba construyendo una máquina de confianza, y no lo sabía, así que dediqué mi esfuerzo inicial exactamente al lugar equivocado. »* ### Prohibir el « pass » desnudo Un verificador es un **sistema de mundo cerrado**: solo puede pronunciarse sobre lo que se le ha dado. Ante una afirmación que ninguna de sus fuentes cubre, no encuentra contradicción y devuelve un veredicto favorable indistinguible de una verificación real. La solución es una restricción de formato: | El informe debe indicar | Por qué | |---|---| | Cuántas afirmaciones se **verificaron** | denominador: sin él, un « OK » no significa nada | | Cuántas se **relacionaron realmente con una fuente** | esa es la tasa de cobertura real, siempre menor | | Cuáles **quedaron fuera de su jurisdicción** | de lo contrario el juez se extralimita y el silencio de otras afirmaciones pasa por acuerdo | | Cuáles **no pertenecen a ninguna fuente del sistema** | ese es el verdadero registro de riesgos de la organización | *« No puedo verificar esto »* debe ser un resultado de primera clase, al mismo nivel que « pass » y « fail ». El antipatrón simétrico es más peligroso que ninguna verificación en absoluto: *« una buena revisión que no vale nada es mucho peor que ninguna revisión, porque blanquea la salida »* — alguien más adelante ve *reviewed: pass* y deja de mirar. Referencia cruzada [[willison-fable-judgement-delegation-subagents-2026-07-03]]. ### La verificación que la revisión por activo individual no puede producir Dos activos de la misma campaña pueden ser cada uno individualmente correcto, cada uno trazable a una fuente real, cada uno validado — y aun así contradecirse entre sí. Verificar contra la capa de verdad y verificar activos entre sí son **dos verificaciones distintas**; la primera no puede producir la segunda. El diagnóstico del autor: *« si ejecutas campañas multi-activo y solo verificas un activo a la vez, tienes este bug ahora mismo. »* Transposición fuera del marketing: un PR que toca tres archivos, un conjunto de specs generado por lotes, un documento y su código producidos juntos. La coherencia cruzada es una verificación a nivel de bundle, nunca una suma de verificaciones unitarias. ### La capa de verdad Fallo relatado: los hechos del producto vivían **dentro** de la skill que escribía los artículos, y luego el mismo hecho tenía que existir en la skill de email, en la battlecard, en la página web. *« En pocas semanas tenía cuatro versiones ligeramente distintas de nuestra fecha de lanzamiento en cuatro archivos distintos, y la deriva era invisible porque cada archivo era individualmente plausible. »* Regla: *« un documento que declara hechos y un documento que produce contenido son dos documentos distintos, con dos propietarios distintos »*, cada uno versionado y fechado. Nada que produzca contenido tiene permitido contener un hecho — tiene que solicitarlo. Beneficio: un hecho cambia, lo cambias una vez, las 35 skills son correctas al día siguiente; una afirmación se disputa, solo hay un lugar donde mirar. Por qué nadie la construye: *« No puedes hacer una demo de una capa de verdad. Solo puedes hacer una demo de lo que evita, que no es nada visible. »* Ejercicio propuesto: abrir los últimos cinco activos producidos, resaltar cada afirmación factual, nombrar para cada una el único documento propietario — *« aquellas a las que no puedes asignar un propietario son tu verdadero registro de riesgos. »* Extiende [[vasilopoulos-codified-context-infrastructure-ai-agents-2026-02-24]]. ### Dos lecciones sobre las skills 1. **El contrato de salida tiene que ser paranoico con la ambigüedad.** Durante semanas, la skill de « entrada de blog » escribió **descripciones de artículos** — encabezados de sección seguidos de una frase que explicaba lo que cubriría la sección, *« absolutamente cada vez »* — y superó todas las revisiones, porque la estructura era impecable. Causa: una línea ambigua en la plantilla (*« la entrada, bajo los encabezados de sección propios del enfoque »*), leída razonablemente como una solicitud de esquema. Detalle organizativo más importante que el bug: nadie lo señaló, *« la gente asume que la herramienta tiene razón y que son ellos quienes la usan mal. »* 2. **El trabajo más importante de una skill es describir para qué no sirve.** Pasadas unas treinta skills, el problema deja de ser calidad y pasa a ser **enrutamiento**: dos skills que ambas manejan de forma plausible « escríbeme algo para ventas » compiten por cada solicitud, y el ganador arbitrario produce el formato equivocado. La mitad de cada descripción se convirtió en un límite explícito. Comparar con [[shihipar-claude-code-lessons-building-skills-2026-06-03]]. ### Del prompt a la fontanería Las reglas de voz prohibían las rayas largas, cada prompt lo decía, los testers siguieron encontrándolas durante semanas: *« seguía repitiendo la regla más fuerte, lo cual es una solución probabilística a un problema cuya solución determinista estaba justo ahí. »* Solución: una única función del lado de la salida que las elimina. Heurística generalizable: *« si te sorprendes repitiendo una instrucción, esa es la señal de sacarla del prompt y ponerla en la fontanería »*, con su corolario — *« pedir amablemente no es un control. »* ### El fallo silencioso Una constante destinada a contener un carácter marcador invisible se había vaciado a una cadena en blanco. Sin diff visible, sin error. Más adelante, un paso de limpieza empezó a hacer coincidir cada dígito de cada prompt y a eliminarlo: `« 7,1% en más de 6.000 organizaciones, 2500 palabras »` llegaba al modelo como `« ,% en más de , organizaciones, palabras »`. Cada estadística, fecha, recuento de palabras y número de sección se eliminó silenciosamente, durante un número desconocido de versiones. Esa era la verdadera razón por la que las cifras citadas seguían saliendo mal — *« y había pasado semanas culpando a la tendencia del modelo a inventar números. Los inventaba porque yo los había eliminado. »* Principio: *« El software tradicional se cae cuando se rompe. Estos sistemas siguen funcionando, con confianza, con calidad reducida, y producen algo que parece correcto. »* Dos soluciones: probar **el pipeline**, no solo la salida — una prueba cuya única función es verificar que los números sobreviven un recorrido de ida y vuelta por el ensamblaje del prompt; y recordar que la validación tiene los mismos huecos que el sistema — un campo limitado a 500 caracteres se quedó en 688 durante dos versiones porque el script verificaba todos los demás límites excepto ese. Regla de diagnóstico: antes de acusar a un modelo de inventar un número, verificar que el número realmente le llegó. ### Capa 4, distribución interna *« Aquí es donde mueren en silencio la mayoría de los proyectos internos de IA. No por fallo técnico. Por ser técnicamente excelentes y ser usados por cuatro personas. »* El autor había construido primero para sí mismo — un plugin que requería fluidez en línea de comandos, lo cual describía a seis personas de sesenta. Solución: el mismo sistema construido dos veces, el mismo conocimiento y las mismas verificaciones, dos puntos de entrada — un plugin para constructores, una aplicación de navegador para el resto (catálogo, tres campos, un borrador con sus verificaciones al lado como botones). El punto más fino de la sección: **la adopción sigue a la confianza, no a la capacidad**. La herramienta se usó más una vez que la salida empezó a admitir lo que no sabía con certeza — *« Un borrador que marca "este ejemplo de cliente es ilustrativo, encuentra uno real antes de publicar" se usa. Un borrador que presenta con confianza un ejemplo de cliente inventado se usa una vez, avergüenza a alguien, y la herramienta muere por el boca a boca. »* ### Enseñar al sistema a rechazar La última pieza adapta un activo para otro segmento de mercado y conoce el segmento que la empresa decidió no perseguir: al pedírsele ese segmento, se niega y explica por qué. *« Mismo principio que la declaración de cobertura. Un sistema que solo puede decir que sí te entregará con confianza lo incorrecto para siempre, y no podrás distinguir "esto es correcto" de "esta era la única respuesta disponible". »* Rechazar y admitir ignorancia son la misma primitiva: la capacidad del sistema de delimitar su propio dominio de competencia. ### Las tres incertidumbres que quedan abiertas 1. **¿Capa de verdad incrustada o recuperada en vivo?** *« Las copias incrustadas quedan obsoletas sin que nadie lo note. Las recuperaciones en vivo son lentas y se rompen cuando alguien renombra una carpeta. »* El autor hace una mezcla y dice que no es razonada. 2. **¿El coste de verificación sigue siendo sostenible?** Un activo completamente verificado cuesta *« varias veces »* un borrador en bruto: rentable para trabajo de cara al público, probablemente no para un resumen interno, *« y la línea entre ambos es más difusa de lo que mi sistema afirma. »* Variable de gobernanza a instrumentar primero: un nivel de verificación ligado a la criticidad del activo. 3. **¿Cuánto de esto sobrevive a las próximas dos generaciones de modelos?** Su apuesta, presentada como tal: la capa de verdad y la disciplina de cobertura sobreviven, porque *« resuelven un problema organizativo de procedencia y propiedad que existiría incluso con un modelo perfecto. »* ### El plan « si empiezas el lunes » 1. Anotar los **diez hechos** que el equipo repite más, con un propietario y una fecha para cada uno — versión cero de la capa de verdad, *« lleva una tarde. »* 2. Tomar tu mejor prompt y extraer de él cada hecho hacia ese documento; hacer que el prompt los solicite. 3. Construir un paso de verificación que se ejecute **en una sesión nueva**, vea solo el borrador y las fuentes, y deba indicar lo que no pudo verificar. 4. Encontrar lo que se sigue repitiendo en los prompts y trasladarlo a código. 5. Mostrárselo a alguien no técnico y observar cómo lo usa sin ayuda. Prueba de referencia a ejecutar antes que nada: pasar un activo **ya publicado** por la verificación en una sesión completamente nueva, sin más contexto que el borrador y las fuentes. *« Lo que sale es tu línea base de calidad real. Suele ser humillante. La mía lo fue. »*

## RésuméDe400mots

Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), sobre un sistema interno de IA de marketing construido **en Claude** para un equipo de unas sesenta personas: alrededor de treinta skills, una decena de módulos de verdad, **siete agentes, seis de los cuales solo verifican trabajo**, un plugin de terminal, una aplicación de navegador y una orquestación de campañas multi-activo.

**La tesis.** *« Pensaba que estaba construyendo una máquina de contenido. Estaba construyendo una máquina de confianza. »* La calidad de una salida de IA no se determina en la generación, sino por **lo que el sistema sabe de antemano** y **lo que ocurre con el borrador después**. La generación es la parte fácil — y la única parte que la mayoría de los equipos ha construido.

**Cuatro capas.** *Verdad*: documentos de hechos separados de todo lo que produce contenido, cada uno con un propietario, versionado y fechado. Dejar los hechos dentro de las skills produjo **cuatro versiones de una fecha de lanzamiento en cuatro archivos**, cada una individualmente plausible. *Producción*: la skill de blog pasó semanas escribiendo **descripciones de artículos** en lugar de artículos, y superó todas las revisiones, porque la revisión verificaba la estructura. Superadas las treinta skills, el problema se convierte en **enrutamiento** — la mitad de cada descripción de skill tiene que indicar para qué no sirve. *Verificación*: la capa que separa una demo de un sistema. *Distribución interna*: donde los proyectos mueren por ser excelentes y ser usados por cuatro personas.

**Los dos fallos centrales.** Un fact-checker recibe una afirmación que ninguna de sus fuentes cubre: devuelve un « pass ». *« No solo pasó por alto el error, lo certificó. »* Solución: un verificador es un **sistema de mundo cerrado**; **tiene prohibido devolver un « pass » desnudo** y debe declarar su cobertura — cuántas afirmaciones verificó, cuántas realmente coincidieron, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« Una afirmación no verificable es un hallazgo, no un silencio. »* Segundo fallo: **dos activos individualmente correctos pueden contradecirse entre sí**; la verificación por activo individual no puede detectarlo, por construcción.

**Cinco reglas transversales.** Nunca pedirle a un modelo algo que se puede imponer en código. Los **fallos silenciosos** son todo el riesgo — una constante vaciada eliminó todos los números de todos los prompts, y se culpó al modelo de alucinar. Probar el pipeline, no solo la salida. Tu validación tiene los mismos huecos que tu sistema. **Enseñar al sistema a rechazar.**

**La adopción sigue a la confianza, no a la capacidad**: una salida que admite lo que no sabe con certeza se usa. Cláusula de cierre: ***« La generación es gratis. La confianza es el producto. »***

## 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/es/fiches/dumortier-marketing-ai-os-verification-2026-08-12/