La evaluación es el producto

Un sistema convencional falla en voz alta. Lanza una excepción, no devuelve nada, se cae. La falla se anuncia sola, y el monitoreo la detecta antes que el usuario.

Un modelo de lenguaje falla en silencio y con oraciones completas. Produce una respuesta fluida, bien estructurada y segura de sí misma, que resulta estar mal. Nada se cae. Ninguna alerta se dispara. La salida se ve idéntica a las que estaban bien.

Esa sola propiedad cambia lo que significa entregar. Los programas que he visto llegar a producción lo entendieron temprano. Los que se atoraron trataron la evaluación como una compuerta de calidad cerca del final.

En un entorno regulado la conclusión es más filosa. El framework de evaluación, la traza de auditoría y el modelo de supervisión humana no rodean al entregable. Son el entregable. El modelo es un componente.

Un número de exactitud no es una evaluación

Los pilotos reportan una sola cifra. Noventa y cuatro por ciento de exactitud. El número casi siempre es cierto y casi nunca sirve, porque es un promedio sobre un conjunto de prueba que alguien armó, y el riesgo no vive en el promedio.

Las preguntas que le dan sentido a una cifra: exacto en qué categorías de entrada, medido contra qué verdad de referencia, establecida por quién, sobre datos de cuándo. Un sistema que corre al 94% general y al 60% en el ocho por ciento de casos con consecuencia legal no es un sistema de 94%. Es un sistema con un hueco específico y localizable, y el agregado es justo lo que lo esconde.

La evaluación en producción es estratificada. Defines los segmentos donde equivocarse sale caro y los mides aparte, de forma permanente, con sus propios umbrales. Un modelo que se equivoca tres por ciento de las veces no es un problema de tres por ciento. Es un problema en el tres por ciento que a nadie se le ocurrió revisar.

Alguien tiene que escribir qué es inaceptable

Todos los programas atorados a los que he entrado tenían el mismo hueco. El equipo sabía describir con detalle cómo se ve una buena salida. Nadie había escrito cómo se ve una inaceptable.

Es más difícil de lo que suena y no es una tarea técnica. Requiere que negocio, legal y el área clínica o de cumplimiento se pongan de acuerdo, por escrito, sobre las categorías de lo incorrecto. Una fabricación dicha con seguridad. Una respuesta correcta que revela algo que no debía. Una negativa donde el sistema debió responder. Una respuesta correcta e inservible porque no se puede rastrear.

Mientras esas categorías no existan no hay contra qué medir, no hay umbral que se pueda cruzar, y no hay base para que nadie firme. Los equipos se lo saltan porque es incómodo: escribir cómo se ve la falla obliga a nombrar quién responde por cada tipo de falla. Esa incomodidad es el trabajo.

Una evaluación sin nombre es un documento

La aprobación tiene que pertenecerle a una persona. No a un comité, no a un área. Un nombre que aparece junto a la decisión de que este sistema puede operar.

Lo mismo aguas abajo. Cuando el sistema produzca algo inaceptable en producción, y lo va a producir, tres cosas tienen que existir de antemano: quién se entera, en cuánto tiempo, y quién tiene la facultad de apagarlo. Si apagarlo requiere una junta, el sistema no tiene apagador.

Ahí es donde falla en silencio la mayoría del material de gobierno de IA. Describe principios en lugar de asignar responsabilidad. A un principio no le puedes llamar a las dos de la mañana.

La traza de auditoría es una decisión de diseño, no una bitácora

La bitácora registra lo que el sistema hizo. La traza de auditoría responde otra pregunta, hecha después, por alguien que no estaba ahí: por qué este sistema produjo esta salida, para esta persona, en esta fecha, y si eso estaba dentro de lo aprobado en ese momento.

Responder eso un año después exige cosas que se diseñan desde el principio. Qué versión del modelo. Qué versión del prompt. Qué se recuperó y de dónde. Qué vio el revisor humano y qué hizo con ello. Cuánto tiempo se conserva todo, y quién puede leerlo.

Nada de eso se agrega después a bajo costo. La arquitectura más rápida para la demo casi nunca lo trae, y meterlo al final suele costar más que reconstruir. Esa es una de las razones por las que los pilotos se mueren en el mes catorce y no en el cuatro.

El humano en el circuito es un control, o es un descargo de responsabilidad

"Un humano revisa la salida" aparece en casi todos los planes de programas de IA. En algunos es un control real. En el resto es una frase.

Es un control cuando el revisor tiene criterios explícitos, tiempo suficiente por caso para aplicarlos, autoridad para rechazar, y registro de lo que rechazó. Es un descargo cuando al revisor le pasan cuarenta salidas fluidas y verosímiles por hora, sin criterios y con la expectativa implícita de aprobar.

El segundo arreglo es peor que no revisar, porque fabrica la apariencia de supervisión. El sesgo de automatización está bien documentado: los revisores coinciden con la salida segura de una máquina en tasas altas, y mientras más pulida la salida, mayor la coincidencia. Un sistema generativo produce la salida más pulida que la mayoría de los revisores ha tenido que revisar en su vida.

Así que la pregunta de diseño no es si hay un humano en el circuito. Es sobre qué se mide a ese humano, y si el proceso es capaz de producir un rechazo siquiera.

Cómo se ve esto en el plan

Todo lo anterior es trabajo de entrega. Tiene alcance, esfuerzo, dueños y lugar en la ruta crítica. Si no aparece así en el plan, no va a pasar, porque nada en la fase de piloto lo obliga.

En concreto. El framework de evaluación es un entregable con nombre y con dueño. La taxonomía de salidas inaceptables la firman negocio y cumplimiento antes de construir, no después. Los requisitos de auditoría son insumos de arquitectura desde el primer día. El modelo de revisión tiene gente asignada, y su tasa de rechazo se reporta como cualquier otra métrica. Los umbrales que detendrían el despliegue se acuerdan mientras todos siguen tranquilos.

Arranca más lento y termina muchísimo más rápido, que es la única velocidad que ha importado siempre.

La parte que nadie quiere oír

Los equipos se resisten porque se siente burocracia atornillada a algo emocionante. Es lo contrario. El aparato de evaluación es lo que permite confiarle trabajo real al sistema, y esa confianza es todo el valor.

Un modelo en el que nadie está dispuesto a confiar sin supervisión no automatizó nada. Agregó una fila de revisión.

Las organizaciones que están metiendo IA generativa a producción en entornos regulados no son las que tienen mejores modelos. Todos tienen acceso más o menos a los mismos modelos. Son las que construyeron el aparato que hace seguro depender de un sistema probabilístico.

Ese aparato es el producto. El modelo es un componente.