El verificador ciego: qué puede ver nuestra puerta anti-fabricación

En julio de 2026 probamos el verificador que protege nuestro pipeline de cumplimiento multietapa contra fabricaciones insertando hechos falsos en sus entradas. La mayoría de las fabricaciones plantadas pasaron desapercibidas. Ese resultado parecía un agujero de seguridad en el único componente cuya función es detectar fabricaciones. No lo era, y la razón por la que no lo era es una regla de diseño que ahora tratamos como un principio permanente.

La prueba de plantación había introducido sus hechos falsos en el brief de razonamiento, el único documento que el verificador está contratado para tratar como verdad decidida, y luego contó cuántos el verificador marcó. Medido de esa manera, el verificador no habría superado una prueba de competencia sobre detección de fabricaciones. Mientras tanto, la solución intuitiva a la que todos recurren —permitir que el verificador marque cualquier hecho del borrador que no aparezca en el brief— hizo algo peor que pasar por alto las falsificaciones: contra borradores limpios marcó 9 de 9 en una familia de modelos y 3 de 9 en otra. Y el contrato estrecho que mantuvimos detectó, en una ejecución real de producción, la clase de fallo que su alcance realmente cubre: una cita que el borrador afirmaba y que el conjunto aprobado del brief no contenía.

Llamamos verificador ciego al principio detrás de esto: una puerta anti-fabricación debe delimitarse estrictamente a lo que realmente puede ver. La única ampliación que medimos juzgó la verdad sin acceso a las fuentes y marcó la mayoría de los borradores limpios mientras no detectaba ninguna de las falsificaciones que motivaron su creación. La verificación de honestidad debe ser mecánica, y mecánica significa que la respuesta reside en las entradas.

La prueba que nos mintió

El pipeline es Beyond, nuestro modo de generación de documentos multietapa. Un modelo planificador lee la tarea y escribe un brief de razonamiento. Un modelo ejecutor renderiza cada paso planificado contra ese brief. Un modelo verificador evalúa cada borrador del paso antes de que se libere al usuario. (Una cuarta etapa resume la ejecución terminada; no forma parte de esta historia). Los tres roles de evaluación reciben entradas diferentes, y esa diferencia es el punto central de esta publicación.

Nuestro verificador es deliberadamente ciego. Tanto el planificador como el ejecutor ven el contexto completo: historial de conversaciones, memorias del espacio de trabajo, archivos del espacio de trabajo, contenido de documentos cargados y conocimiento del marco inyectado. El verificador solo ve dos documentos: el brief y el borrador bajo revisión. Su contrato trata los hechos y juicios del brief como decididos, y su función es verificar que el borrador se mantuvo fiel a ellos.

La prueba de laboratorio violó esa premisa sin darse cuenta. Insertamos hechos fabricados manualmente en un brief vacío, ejecutamos el verificador y contamos cuántas de las falsificaciones plantadas marcó. Marcó pocas; la mayoría de las falsificaciones plantadas pasaron. Llamamos roto al verificador. Lo que el experimento midió realmente fue si el verificador cuestionaría el documento que está contratado para confiar. Se negó, como estaba diseñado.

En la misma ventana, una ejecución de producción reveló lo que parecía ser la prueba irrefutable: un hecho organizacional en la salida liberada que ningún insumo que verificamos contenía. Antes de implementar una solución, lo retiramos nosotros mismos: el "hecho fabricado" estaba en un archivo cargado que el ejecutor había leído legítimamente. El hecho estaba fundamentado. Nuestra verificación puntual, como el verificador, simplemente no había mirado ese archivo. Un investigador que no puede ver las fuentes tampoco puede juzgar la fundamentación. Habíamos repetido el mismo experimento roto en nosotros mismos que habíamos hecho en el modelo.

La trampa medida

Así que nos volcamos al lado del borrador, donde las entradas del verificador realmente difieren. La solución intuitiva: marcar cualquier afirmación factual en el borrador que no aparezca en el brief. Construimos exactamente esa regla y la medimos contra borradores limpios, borradores que no contenían fabricaciones en absoluto, generados por las familias de modelos que el pipeline ejecutaba en ese momento. La medición y la decisión de rechazar la regla están registradas en el comentario de diseño del contrato entregado y en el historial de commits; el trabajo se realizó y registró en la sesión de revisión del 22 de julio de 2026:

Regla en prueba	Borradores limpios marcados	Borradores generados por
Marcar hechos del borrador ausentes del brief	9 de 9	GLM 5.2
Marcar hechos del borrador ausentes del brief	3 de 9	Grok 4.20

Una puerta que rechaza la mayoría o todos los borradores limpios no es una puerta; es un corte de servicio. En GLM 5.2, cada borrador limpio probado habría, como mínimo, desencadenado un re-renderizado; lo que habría producido un segundo fallo de verificación (una bandera de advertencia o una detención) no lo medimos. El mecanismo es estructural. Un hecho en el borrador que está ausente del brief no es evidencia de fabricación, porque el ejecutor está permitido, por diseño, fundamentar hechos en fuentes que el verificador no puede ver. Para juzgar "¿esta afirmación es real?", un verificador sin acceso a las fuentes solo tiene sus creencias previas, y el trabajo de cumplimiento es el dominio donde las creencias previas fallan en ambas direcciones: los hechos verdaderos son específicos del espacio de trabajo del cliente, y los falsos son plausibles.

Observa qué tampoco podía hacer la regla ampliada: detectar ninguna falsificación de la prueba de plantación, porque esas falsificaciones vivían en el brief, que tanto el contrato estrecho como la regla ampliada tratan como verdad. Por construcción, la ampliación no añadió ningún recall sobre esa clase; nuestras mediciones con borradores limpios mostraron lo que sí añadió. Ese par de resultados es lo que nos convenció de que el mandato, no el modelo, era el problema.

El contrato que sobrevivió

Lo que el verificador tiene permitido juzgar está escrito en su prompt entregado, y el límite es nítido. Por paso, hace cumplir dos contratos y nada más:

1. El contrato propio del paso: el borrador entrega lo que requieren el título y la especificación de contenido de este paso. La ausencia de contenido solo es una violación cuando la especificación propia del paso lo exige.
2. Los juicios y citas del brief como restricciones globales, donde exactamente tres cosas son violaciones:
   • contradicción: una afirmación en el borrador que contradice directamente una viñeta de juicio o la especificación del paso,
   • cita alterada: una cita del brief reproducida incorrectamente (cláusula, artículo o redacción de requisito incorrectos),
   • cita o requisito inventado: una cita o requisito de marco afirmado en el borrador que el brief no contiene.

La ausencia nunca es una violación de las restricciones globales. El brief enruta contenido a través de los pasos; un paso de correo electrónico de partes interesadas omite correctamente las citas a nivel de cláusula que pertenecen al paso de política. El verificador no juzga estilo, tono, longitud ni calidad general. Un borrador plano que sea fiel a su paso aprueba.

Esta forma fue impuesta por la medición, dos veces. Primero, una calibración en producción real el 11 de junio de 2026, en la topología de lanzamiento cuyo verificador era Claude Haiku 4.5 (el conjunto de tareas de la sesión no se registró en el log duradero; la afirmación duradera es el recuento de problemas a continuación): de 12 problemas del verificador planteados durante el uso real, 2 eran reales y 10 eran banderas demasiado literales en borradores que, de hecho, eran fieles. (Esta métrica cuenta problemas marcados, no rechazos de borradores limpios). Segundo, las mediciones de 9 de 9 y 3 de 9 borradores limpios mencionadas anteriormente. Ambas mediciones condenaron el mandato más amplio, cada una en su propio eje de falsos positivos; el alcance estrecho se mantuvo enfocado en la clase de fallo que importa.

La estrechez no es una debilidad. Es lo que mantiene la verificación respondible. "¿Este borrador contradice el brief?" es una pregunta cuya respuesta vive enteramente en los dos documentos frente al verificador; no se requieren hechos externos para resolverla. "¿Esta afirmación es verdadera?" no es ese tipo de pregunta, y ninguna ingeniería de prompt que medimos la convierte en una.

Qué detecta la fabricación en su lugar

Si el verificador ciego solo verifica la fidelidad, ¿qué hay entre el usuario y una salida fabricada? Tres capas, cada una delimitada a una verificación que no necesita hechos más allá de sus propias entradas:

Citas contra una lista cerrada. El brief lleva un conjunto explícito de citas. Las instrucciones del ejecutor dicen: reproducir las citas del brief exactamente como están escritas; nunca omitir, alterar ni inventar citas de marco. Si un número de cláusula pertenece a una lista finita y conocida es verificable sin ver ninguna fuente. En un dominio de cumplimiento, ese mundo cerrado es el objetivo correcto: la salida peligrosa no es una paráfrasis, es una cita a un texto que el conjunto aprobado no autoriza.

Una puerta de integridad donde sí existe una fuente. En ejecuciones que realizaron investigación web, el pipeline adicionalmente verifica las URLs y precios de salida contra el conjunto de evidencia aprobado, porque allí la verdad de fondo es accesible y finita.

Fontanería de fallo-cerrado, con una excepción deliberada. El veredicto del verificador es la única salida legible por máquina en el pipeline, un objeto JSON estricto con un booleano de aprobación y una lista de problemas que debe coincidir con él. Un veredicto que no puede analizarse lanza un error, nunca aprueba. Un veredicto fallido desencadena exactamente un re-renderizado con la lista de problemas, luego una re-verificación; un segundo fallo libera el paso con una bandera de advertencia, después de haber sido inspeccionado dos veces. Una interrupción del verificador o un veredicto no analizable obtiene un intento de reintento, luego se detiene la ejecución, y el paso en curso nunca se libera. La excepción importa y vale la pena enunciarla con exactitud: fallo-cerrado se aplica a la inspección, no a la corrección. Una aprobación significa que el verificador no detectó ninguna violación de contrato, lo que no es una garantía de verdad de un modelo imperfecto, y un borrador marcado con dos fallos no aprobó nada.

La detección, en vivo

El 2 de septiembre de 2026 ejecutamos una sonda de una sola tarea a través de nuestro pipeline de producción en nuestra propia cuenta de pago: una tarea que escribimos nosotros mismos, sin material de cliente cargado. El propósito era la prueba de extremo a extremo de la topología de cuatro roles en prueba ese día, que ejecutó cada rol en GLM 5.3 (esfuerzo alto en el planificador, bajo en el ejecutor, verificador y resumen). La tarea: redactar un breve esquema de política de registro de activos para la norma ISO/IEC 27001:2022 Anexo A, de una página.

El borrador del ejecutor citó las cláusulas 9.2 y 9.3 de la norma ISO/IEC 27001:2022, las cláusulas de auditoría interna y revisión por la dirección. Ambas cláusulas existen en la norma; la cita es exactamente lo que un documento de cumplimiento con apariencia competente buscaría. El problema es contractual, no factual: el conjunto de citas aprobado del brief no las contenía, lo que las convierte en citas inventadas en el sentido del contrato, citas afirmadas en el borrador que el brief no autoriza. El verificador devolvió un veredicto de fallo nombrando el problema, el ejecutor re-renderizó con las citas dentro del conjunto aprobado, y el segundo intento aprobó. La ejecución se completó en 155 segundos sin advertencias ni truncamientos, todas las llamadas en GLM 5.3.

Dos propiedades de esa detección importan más que la anécdota. Primero, la clase: el fallo que realmente ocurrió en producción fue una cita que excedía el conjunto aprobado, precisamente la violación que la verificación ciega cubre, no un hecho plantado manualmente. Segundo, el tamaño de la verificación: el verificador funcionó con bajo esfuerzo de razonamiento y vio dos documentos. En la misma evaluación semanal de la topología (1 de septiembre de 2026: cinco tareas difíciles que cubren disciplina de alcance, omisión de audiencia, corrección de citas, consistencia entre documentos y manejo de evidencia no verificada; tres pruebas por tarea por brazo; 30 ejecuciones en total en dos brazos, GLM 5.3 y un brazo proxy Grok 4.20), el brazo GLM 5.3 del verificador devolvió un veredicto JSON estricto analizable en las 15 de sus ejecuciones, sin detenciones. La evaluación fue independiente: Claude Haiku 4.5, ejecutado a través de OpenRouter. La puerta que detectó el fallo de producción es la llamada de modelo más restringida del pipeline.

Lo que esto no afirma

La detección de producción es un único punto de datos de una sonda deliberada, no una estimación de tasa. El arnés de prueba de plantación fue un archivo interno de borrador que no conservamos; respaldamos su resultado cualitativo (la mayoría de las falsificaciones plantadas pasaron, tasa de detección registrada aproximadamente una de cada cuatro en ese momento) pero no lo publicamos como medición precisa, porque los artefactos, versiones de modelos y conjunto de tareas detrás de él no estaban congelados. El registro duradero de la prueba de la regla ampliada son las mediciones de 9 de 9 y 3 de 9 borradores limpios en el comentario del contrato entregado, medidas y registradas el 22 de julio de 2026; el registro nombra las familias generadoras de borradores (GLM 5.2, Grok 4.20) pero no nombra el modelo verificador ni el conjunto de tareas, por lo que solo atribuimos los borradores, y no hemos re-ejecutado la prueba en otras familias. La investigación de la ejecución retirada de julio precede a nuestra disciplina actual de evidencia, por lo que la describimos sin identificadores de ejecución ni atribución de modelos. El riesgo residual es real y está documentado en el repositorio: en ejecuciones sin investigación web, un hecho organizacional inventado por el ejecutor, distinto de una cita inventada, aún no tiene una puerta automatizada, y no hemos medido con qué frecuencia ocurre; solucionarlo significaría dar al verificador las fuentes, un rediseño, no una cláusula de prompt. Todo aquí es un momento puntual a partir de las fechas marcadas: contrato y código a partir del 16 de septiembre de 2026, sonda del 2 de septiembre de 2026, evaluación del 1 de septiembre de 2026, calibración en producción real del 11 de junio de 2026, medición de la regla ampliada del 22 de julio de 2026.

La lista de verificación

Antes de confiar, ampliar o "arreglar" una puerta de verificación en tu propio pipeline de agentes:

1. Decide qué puede ver el verificador, y deja que eso decida qué puede juzgar. Ciego a las fuentes significa fidelidad únicamente: contradicciones, citas alteradas, citas inventadas.
2. La ausencia de una referencia que el productor puede legítimamente exceder nunca es una violación. Si no puedes probar que el hecho fue fabricado en lugar de fundamentado en una fuente que no pasaste, no lo marques.
3. Haz que la honestidad sea mecánica donde tu dominio lo permita. Citas contra una lista cerrada, URLs y precios contra un conjunto de evidencia aprobado: estas son verificables a partir de las entradas. La verdad abierta no lo es.
4. Calibra con borradores reales antes de confiar en la puerta. Mide tu parte de falsos positivos antes de ampliar el contrato; la nuestra fue de 10 de 12 problemas en uso real (11 de junio de 2026). Diseña el contrato para que la ausencia no sea una violación.
5. Un veredicto que no puede analizarse debe detener el paso, nunca aprobarlo. Mantén un único veredicto legible por máquina y haz que el booleano de aprobación coincida con la lista de problemas.
6. Un re-renderizado en un veredicto fallido, luego una re-verificación. Libera un paso con dos fallos solo con una bandera de advertencia, después de dos inspecciones. Nunca liberes contenido no inspeccionado en ninguna ruta, incluyendo interrupciones del verificador. Una aprobación significa que no se detectó ninguna violación de contrato, no que el contenido sea verdadero.
7. Prueba con la clase de fallo que tu dominio realmente produce (para nosotros, citas que exceden el conjunto aprobado), no con la clase más fácil de simular (hechos plantados manualmente). Y ten cuidado con dónde los plantas: una falsificación escrita en el documento de verdad del verificador no prueba nada sobre la fabricación.
8. Cuando tu propia investigación de una supuesta fabricación depende de entradas que no verificaste, tú eres el verificador ciego. Retírate primero, mide después.

Un verificador que ve menos no es una puerta más débil. Sus veredictos siguen siendo verificables, porque juzga el único contrato que el productor recibió realmente.