¿Qué cuenta como evidencia cuando la máquina es probabilística?
La probabilidad no es un veredicto
Cuando una máquina devuelve 0.87, la primera pregunta suele ser demasiado pequeña. La gente pregunta si 0.87 es alto. ¿Alto comparado con qué, para qué resultado, sobre qué casos y para qué decisión? Un número impreso junto a una salida parece una propiedad de esa salida. A menudo no lo es. Es un intento de describir una relación entre un modelo, una población definida de casos y un resultado observado a lo largo del tiempo. Esa relación puede ser útil. Puede guiar una cola de revisión, fijar un umbral o indicar a un operador cuándo un resultado merece una segunda mirada. Pero no convierte una predicción individual en un hecho con un decimal adjunto.
Este es el punto incómodo en el centro de los sistemas probabilísticos. Sus salidas suelen ser más informativas que una etiqueta desnuda, porque pueden expresar grados de respaldo o incertidumbre. También son más fáciles de sobreinterpretar. Una puntuación puede tratarse como una declaración de testigo, una conclusión legal, un diagnóstico o un permiso. No es ninguna de esas cosas por defecto. La evidencia comienza cuando la organización puede decir qué representa el número, cómo se comprobó, dónde se aplica esa comprobación y qué acción se le permite cambiar al número.
Esa distinción importa mucho antes de que un sistema se encuentre con un regulador. Un equipo puede estar decidiendo si un documento sugerido necesita una revisión humana. Un comprador puede estar comparando dos proveedores que ambos anuncian medidas de confianza. Un operador puede estar estableciendo una regla de escalado. Un organismo público puede estar preguntándose si una lista clasificada es lo bastante buena para influir en dónde va primero la atención. En todos los casos, una ejecución exitosa es evidencia de una sola cosa: que esa ejecución produjo una salida. Todavía no es evidencia de que el sistema merezca la autoridad que se le atribuye.
La respuesta sensata no es prohibir las probabilidades en el trabajo de consecuencias. Es darles una descripción de puesto adecuada. Una probabilidad puede respaldar una decisión cuando está vinculada a un evento definido, una población relevante, un método de observación, un límite de incertidumbre y una regla para lo que ocurre cuando la evidencia es débil. Esto es más lento que admirar un solo número y mucho más rápido que descubrir más tarde que nadie puede explicar qué se suponía que debía hacer el número.
La evidencia tiene que nombrar su pregunta
La evidencia nunca está simplemente presente. Es evidencia a favor de una proposición. Un resultado de prueba puede respaldar la proposición de que un componente produce una salida concreta para una entrada concreta bajo una configuración concreta. Puede respaldar la proposición de que un modelo clasifica bien los ejemplos en un conjunto de datos reservado. Puede respaldar la proposición de que una estimación de probabilidad se corresponde razonablemente con las frecuencias observadas en un conjunto de evaluación definido. Esas proposiciones son distintas. La disciplina comienza por escribir la proposición antes de elegir la métrica.
Consideremos la afirmación aparentemente sencilla de que un sistema es preciso. ¿Preciso en qué? Una precisión de clasificación puede describir con qué frecuencia la clase con mayor puntuación coincidió con una etiqueta. No dice si la probabilidad declarada estaba bien calibrada. Una métrica de ranking puede describir el orden, no la calidad de la escala de puntuación. Un error medio bajo puede coexistir con un patrón de error perjudicial en un subgrupo o en un umbral que desencadena una acción. La métrica no es incorrecta. El salto de la métrica a la conclusión operativa es donde suele empezar el problema.
El trabajo de la OCDE sobre instrumentos de evaluación es útil precisamente porque renuncia a la fantasía de que una sola puntuación puede contener toda la explicación. Su marco distingue facetas como la cobertura, el propósito, el realismo, la fiabilidad, la reproducibilidad, la objetividad y la parcialidad. No son adornos burocráticos alrededor de un punto de referencia. Describen si el resultado guarda la relación correcta con la pregunta que se plantea. Una comparación de investigación, una evaluación de conformidad y una decisión operativa de publicación pueden usar pruebas. No les piden lo mismo a esas pruebas.
Empiece, pues, con una frase con la que se pueda discrepar. Por ejemplo: este sistema puede derivar casos a revisión humana cuando su estimación de probabilidad documentada para un resultado definido supera un umbral especificado, siempre que la entrada coincida con el ámbito validado y el revisor conserve la autoridad para rechazar la sugerencia. Esa es una proposición operativa discutible. Nombra la acción, la condición y el límite. No finge que una puntuación ha elegido por sí sola su papel en el mundo.
La frase contraria resulta familiar porque es cómoda: el modelo tiene un 87 por ciento de confianza. Incluso cuando un modelo emite realmente una probabilidad, la frase omite el evento, la evidencia de calibración, la población, el período y la decisión. Convierte una relación en un rasgo de personalidad. Las máquinas no necesitan ser descritas como tímidas o seguras. Necesitan ser descritas como sistemas cuyas salidas tienen significados definidos y límites definidos.
La confianza no es lo mismo que la corrección
Un sistema puede estar seguro y equivocarse. También puede ser correcto mientras expresa poca confianza. Esos dos hechos no sorprenden una vez que se mantienen separados los términos. La corrección pregunta si un resultado coincidió con la referencia elegida para un caso. La confianza es una declaración adjunta a una salida, a menudo derivada de una puntuación del modelo o de una transformación de esta. La calibración plantea una pregunta adicional a lo largo de muchos casos: cuando el sistema asigna probabilidades similares, ¿ocurren los resultados aproximadamente a la tasa declarada? Son preguntas relacionadas, pero una buena respuesta no proporciona las demás.
Imaginemos un conjunto de casos para los que un clasificador informa de una probabilidad de 0,80 para un evento definido. Si, en un conjunto adecuadamente descrito y suficientemente grande de casos comparables, el evento ocurre aproximadamente ocho veces de cada diez, la estimación puede considerarse bien calibrada para esa población y condición. Eso no significa que el siguiente caso de 0,80 tenga un destino del ochenta por ciento. Significa que la puntuación ha mostrado una relación con los resultados observados en el conjunto declarado. La expresión en el conjunto declarado hace la mayor parte del trabajo intelectual.
La calibración tampoco es una insignia universal. Una puntuación puede estar bien calibrada sobre un conjunto de datos histórico y mal calibrada cuando cambian la fuente de entrada, la población de usuarios, el flujo de trabajo, el proceso de etiquetado o las condiciones de despliegue. Puede estar bien calibrada en general y comportarse de forma distinta dentro de una parte de la población que importa para el servicio. Puede tener buen aspecto en un grupo amplio y, sin embargo, ocultar una diferencia pronunciada cerca del umbral de decisión. Una gráfica de calibración no es un diploma enmarcado sobre el sistema de producción. Es una observación fechada con un alcance.
La literatura sobre calibración de modelos hace concreta esa separación. Guo y sus colegas estudiaron la calibración de la confianza en redes neuronales modernas y mostraron que la precisión por sí sola no determina si las estimaciones de confianza representan las probabilidades de corrección observadas. Su trabajo también evalúa métodos de calibración mediante posprocesamiento. La lección operativa importante es más limitada que una receta: no debe suponerse que una puntuación de un modelo tiene un significado probabilístico adecuado solo porque se ofrece en un rango cómodo entre cero y uno.
Por eso, una organización cuidadosa registra tres cosas distintas. Registra el rendimiento en la tarea, para poder preguntarse si los resultados cumplen la tarea definida. Registra la calibración u otra propiedad explícita de incertidumbre, para poder preguntarse qué significa la puntuación en la práctica. Y registra la consecuencia de actuar con un umbral determinado, para poder preguntarse si la regla de decisión es adecuada. Combinar las tres en un único indicador verde puede simplificar un panel de control. No simplifica el mundo.
La calibración tiene un denominador
Toda afirmación sobre calibración tiene un denominador. El denominador no es meramente el número de registros de un archivo. Es el conjunto de casos que podían contarse, la forma en que se agruparon, la definición del resultado, el periodo de tiempo, las exclusiones y el proceso que produjo las etiquetas de referencia. Si se eliminan esas condiciones, un diagrama de fiabilidad se convierte en una curva agradable sin jurisdicción sobre una decisión.
Supongamos que una evaluación agrupa las predicciones según la confianza declarada. La tasa observada en cada grupo depende de los casos admitidos en el grupo y de la definición del resultado. ¿Se excluyeron los casos ambiguos? ¿Se trataron las abstenciones como errores, rechazos seguros o algo distinto? ¿La etiqueta representaba un evento inmediato, una revisión posterior o una apelación final? ¿Se conservaron los duplicados? ¿La evaluación incluyó solo los registros que superaron un paso de validación previo? Cada respuesta puede ser razonable. Cada respuesta cambia lo que significa la afirmación de calibración resultante.
Por eso un modelo puede tener un resultado de calibración global respetable y, aun así, no ser adecuado para un uso concreto. El resultado global puede agrupar idiomas, longitudes de entrada, regiones, tipos de dispositivo, recorridos de clientes o modos de funcionamiento que no comparten la misma estructura de error. Una cifra agregada puede ser un resumen honesto y, aun así, ser una evidencia insuficiente para una decisión local. La respuesta correcta no es exigir un modelo separado para cada persona. Es poner a prueba los supuestos de agrupación que la propia decisión vuelve relevantes.
El marco de evaluación de la OCDE llama a esto cobertura. El marco pregunta si un instrumento de evaluación cubre una distribución sesgada o representativa de aquello que pretende medir, y distingue el rendimiento en la tarea de una afirmación más amplia sobre capacidades. Esas distinciones son útiles para la evidencia probabilística. Una puntuación puede ser evidencia sobre el rendimiento en una distribución de tareas. No debería convertirse silenciosamente en evidencia sobre una capacidad, una población afectada o un contexto futuro que la evaluación no cubrió.
El denominador también tiene una vertiente social. Cuando una organización decide qué casos son lo bastante sencillos como para automatizarlos y cuáles deben esperar a una persona, las definiciones determinan quién asume la incertidumbre restante. Una puntuación agregada puede ocultar el hecho de que un grupo más pequeño tenga menos ejemplos, etiquetas menos estables o un contexto operativo distinto. Eso no es motivo para prometer estadísticas iguales donde la evidencia es escasa. Es motivo para informar con claridad de que la evidencia es escasa y para establecer una regla de decisión prudente al respecto.
Una ejecución con éxito es una muestra, no una conclusión
Los sistemas probabilísticos invitan a una forma particular de exceso de confianza porque son muy fáciles de demostrar. Introduce una entrada, recibe una salida impresionante, repite con una entrada parecida, recibe otra. La demostración puede mostrar que el sistema es capaz de realizar la tarea. Puede incluso mostrar algo digno de investigación. No puede mostrar la distribución de los resultados, la estabilidad de la puntuación, la respuesta ante casos límite, la calidad de las etiquetas de referencia ni el efecto de un cambio en las condiciones de despliegue. Una muestra puede iniciar una investigación. No puede concluirla.
Lo mismo se aplica a una única ejecución de referencia. Un resultado puede haberse recopilado correctamente, sobre un sistema bien descrito y con una métrica legítima. Si solo se ejecutó una vez, es evidencia del valor observado una sola vez en esas condiciones. No es automáticamente evidencia de una propiedad estable del sistema. La repetición ayuda a exponer la variación. No elimina la necesidad de preguntarse si la prueba representa el uso previsto. La reproducibilidad y la validez resuelven problemas distintos, y ambas merecen un lugar en el registro.
El marco de la OCDE hace explícita esa separación. La fiabilidad se refiere a si una evaluación presenta suficientes repeticiones, duración de los episodios o instancias para ofrecer una variación baja al volver a aplicarse. La reproducibilidad se refiere a si la misma prueba puede generarse de nuevo, incluido si los componentes estocásticos alteran las interacciones. Una prueba puede ser exactamente reproducible y aun así responder a una pregunta poco útil. Puede ser realista y difícil de reproducir exactamente porque el entorno ha cambiado. Ninguna de las dos condiciones es un defecto por sí misma. El registro debe indicar qué condición se cumple y qué permite inferir al lector.
Aquí hay un hábito operativo modesto pero valioso: conserva la ejecución con éxito, pero no hagas que cargue con más de lo que puede. Preserva la entrada, la configuración, la versión, la semilla cuando corresponda, las dependencias, la salida y la decisión de evaluación. Luego colócala junto a mediciones repetidas, contraejemplos, abstenciones y condiciones modificadas. Un resultado que sigue siendo útil después de enfrentarse a sus vecinos incómodos es más valioso que un resultado que hubo que proteger de ellos.
En los sistemas generativos, una respuesta con éxito es una evidencia especialmente débil de repetibilidad a menos que se registre el contrato de interacción. Los ajustes de muestreo, las indicaciones, el material recuperado, la disponibilidad de herramientas, la versión del modelo, la política de seguridad y el flujo de trabajo circundante pueden condicionar el resultado. Reproducir una cadena de palabras sin el estado relevante puede replicar la apariencia de una prueba y, sin embargo, omitir la condición que la hacía significativa. En el trabajo con evidencia, la semejanza no es una repetición.
La repetibilidad no es sinónimo de confianza
Una repetición determinista puede ser una evidencia excelente para una única proposición acotada: dadas las mismas entradas registradas, configuración y condiciones de implementación, el sistema produjo el mismo resultado. Eso hace que las investigaciones, las pruebas de regresión y las comparaciones de versiones sean más manejables. No establece que el resultado fuera correcto, que la entrada fuera adecuada, que el sistema debiera haberse utilizado para la decisión ni que el resultado vaya a generalizarse más allá de su límite registrado. La repetibilidad es una propiedad del experimento. La confianza es un juicio sobre un acuerdo más amplio.
El comportamiento estocástico modifica el registro en lugar de excusar su ausencia. Si una salida varía, la evaluación debe registrar qué partes varían, con qué frecuencia, dentro de qué rango y cómo afecta esa variación a la decisión. Un sistema que propone formulaciones alternativas puede tolerar un rango más amplio que un sistema que clasifica casos para su atención. Un sistema que asesora a una persona puede exigir pruebas distintas de uno que permite realizar una acción irreversible. La probabilidad no es por sí sola una categoría operativa. La consecuencia determina cuánta incertidumbre puede asumir con seguridad un proceso.
Hay un error fácil de cometer en ambos extremos. Un equipo exige una salida fija a una herramienta cuyo propósito declarado incluye la exploración y luego confunde el determinismo resultante con calidad. Otro equipo acepta una salida variable de un sistema de apoyo a la decisión y luego califica la variabilidad de creativa cuando resulta difícil de evaluar. Ninguna de las dos posturas es seria. La cuestión es si la variación es esperada, acotada, observable y compatible con la autoridad asignada al sistema.
La regulación europea no reduce esta cuestión a una puntuación universal. Para los sistemas de IA de alto riesgo, el artículo 15 del Reglamento de IA exige un nivel adecuado de exactitud, robustez y ciberseguridad, así como un rendimiento coherente en esos aspectos durante todo el ciclo de vida. También indica que los niveles de exactitud y las métricas de exactitud pertinentes deben constar en las instrucciones de uso, y fomenta los puntos de referencia y los métodos de medición para los aspectos técnicos de la medición del rendimiento. La disposición no dice que una sola prueba repetida resuelva la cuestión. Pide que el rendimiento se especifique y se mantenga en su contexto.
Esa es la postura sensata para cualquier evaluación seria. Una prueba repetible es una pieza de la cadena de pruebas. Necesita un responsable, un límite de versión, un desencadenante de cambio y una conexión con la decisión operativa a la que respalda. Sin todo eso, la reproducibilidad puede convertirse en otra palabra atractiva que viaja más lejos que el experimento.
La incertidumbre necesita una vía operativa
La finalidad práctica de la incertidumbre no es hacer que un panel de control parezca sofisticado. Es cambiar lo que el sistema tiene permitido hacer. Si una puntuación no influye en el enrutamiento, la revisión, la explicación, la supervisión o la detención, puede ser una curiosidad técnica más que una señal operativa. Si cambia una acción, la organización debe indicar la vía que va de la puntuación a la autoridad.
Un umbral es una de esas vías, pero no es una línea mágica. Fijar un umbral implica elegir una compensación entre tipos de error, carga de trabajo, demora y posible daño. Un umbral puede ser adecuado para priorizar una cola de revisión de baja consecuencia e inadecuado para denegar a una persona el acceso a un servicio. El mismo umbral numérico puede significar cosas distintas cuando cambian la tasa base, el coste del error, las vías de reparación disponibles y la calidad de la revisión posterior. No hay un número prudente universal esperando en un manual de un proveedor.
Por ese motivo, una regla de decisión debe describir algo más que un punto de corte. Debe indicar el resultado que se estima, las pruebas que respaldan la puntuación, los casos que quedan fuera del alcance, las circunstancias que obligan a abstenerse, la autoridad humana que permanece, el registro que se conservará y las condiciones para revisar la regla. Un umbral sin esos acompañantes es una decisión disfrazada de configuración.
Una hipótesis útil ilustra la cuestión sin inventar un incidente público. Considérese un servicio que utiliza una puntuación de un modelo para ordenar las solicitudes entrantes destinadas a un revisor capacitado. Las pruebas pueden respaldar una afirmación limitada: la puntuación puede ayudar a ordenar solicitudes comparables dentro de una categoría de admisión declarada, mientras que toda la priorización final sigue en manos del revisor. Las mismas pruebas no respaldan el rechazo automático de solicitudes con puntuación baja, porque se trata de una acción distinta con consecuencias distintas y necesidades de prueba distintas. La salida no cambió. Su autoridad sí.
La abstención merece la misma seriedad. Un sistema que puede decir que su evidencia es insuficiente puede generar más trabajo a corto plazo y reducir errores no observados a largo plazo. Pero la abstención solo es útil cuando tiene un destino responsable. Si los casos inciertos desaparecen en una cola sin dueño, el sistema simplemente ha convertido la incertidumbre en demora. Una buena ruta nombra quién recibe el caso, qué puede ver, cómo lo corrige y cómo esa corrección informa la evaluación posterior.
Las afirmaciones causales necesitan más que un gráfico de antes y después
Las estimaciones de probabilidad se usan a menudo para respaldar afirmaciones sobre lo que ocurrirá si una organización actúa. Esa es una tarea probatoria distinta de predecir lo que ocurrió en datos históricos. Un modelo puede estimar que un caso se parece a otros casos con un resultado determinado. Pero eso no demuestra que cambiar el caso, cambiar una política o seguir una recomendación hará que el resultado cambie. La predicción y la intervención no deben fusionarse porque el gráfico se ve ordenado.
Las figuras de antes y después son particularmente tentadoras. Un equipo introduce una herramienta, un resultado cambia, y la herramienta recibe el crédito o la culpa. Pueden haber cambiado muchas otras cosas: la población que entra al servicio, la documentación, el personal, las políticas, las condiciones estacionales, los filtros previos o la propia medición. La observación puede merecer atención. No es una conclusión causal hasta que se hayan abordado la comparación, las explicaciones alternativas y la incertidumbre restante.
Esto importa para la gobernanza de la IA porque un sistema puede ser operativamente influyente mucho antes de ser formalmente decisivo. Una clasificación puede cambiar qué registro abre primero una persona. Un indicador de confianza puede empujar a un revisor a aceptar un resultado. Una acción recomendada puede volverse rutinaria porque la cola está ocupada. La vía causal incluye la interpretación humana, el diseño de la interfaz, los incentivos, la presión de tiempo y la ruta de corrección disponible. Evaluar solo el modelo no puede contar toda la historia.
Cuando una afirmación causal importa, el plan de evidencia debe decir qué comparación haría la afirmación más creíble y qué aún no podría descartar. Eso puede implicar una prueba controlada, un despliegue por fases, una revisión independiente, un diseño observacional cuidadosamente construido, o una decisión de abstenerse de hacer una afirmación causal por completo. La cuestión no es exigir perfección académica a cada cambio operativo. Es hacer coincidir la confianza de la afirmación con la evidencia realmente disponible.
Hay un sentido común de tipo holandés en esto, aunque viaja bien: si solo has medido que el viento cambió, no anuncies que has rediseñado el clima. Una predicción puede ser valiosa sin convertirse en una historia sobre causalidad. La honestidad no es una retirada. Es lo que hace que el resultado sea utilizable para alguien que tiene que decidir qué hacer a continuación.
La precisión puede ocultar una mala regla de decisión
La precisión suele ser útil y a menudo insuficiente. Un sistema puede lograr una alta precisión cuando un resultado es común, mientras ofrece poca ayuda en los casos que más importan. Puede tener un promedio sólido mientras rinde mal cerca del límite de acción. Puede hacer predicciones correctas sin ofrecer estimaciones de probabilidad que respalden umbrales sensatos. Puede parecer exitoso porque la etiqueta de referencia es fácil de predecir, aunque la propia etiqueta sea un proxy débil para la decisión que el servicio necesita tomar.
Nada de esto significa que la precisión carezca de sentido. Significa que el lector debe preguntarse qué mide y qué deja fuera del encuadre. El Reglamento de IA reconoce esta necesidad de contexto en sus requisitos para las instrucciones de uso: la documentación de los sistemas de alto riesgo debe incluir las características y limitaciones de rendimiento, la finalidad prevista, las métricas de precisión pertinentes utilizadas para probar y validar el sistema, y las circunstancias conocidas o razonablemente previsibles que puedan afectar al rendimiento esperado. Una cifra de precisión resulta más útil cuando se mantienen unidas las condiciones que la rodean.
Una buena revisión operativa pregunta, por tanto, por los patrones de error, no solo por los totales. ¿Qué tipos de casos se clasificaron mal? ¿Cuáles resultaron inciertos? ¿Qué casos se excluyeron o se enviaron a revisión? ¿Qué ocurre con un falso positivo, un falso negativo, una respuesta tardía o una abstención injustificada? ¿Quién puede detectar el resultado, impugnarlo y corregir el registro? Esas preguntas devuelven la evaluación al servicio en lugar de dejarla en manos del modelo.
También puede resultar útil distinguir la evidencia de un componente de la evidencia de un flujo de trabajo. Una prueba de componente puede establecer propiedades de un modelo ante entradas definidas. Una evaluación de flujo de trabajo puede establecer cómo interactúan el modelo, la interfaz, los datos, las personas y las políticas. Un componente puede tener una calibración de puntuaciones sólida mientras que el flujo de trabajo produce sesgo de automatización porque la interfaz oculta la incertidumbre. Un flujo de trabajo puede tener un excelente proceso de revisión mientras depende de un componente cuyos datos de origen ya no se ajustan al alcance declarado. Las pruebas deben encontrarse en algún punto.
La evidencia resultante no es necesariamente un gran informe. Puede ser un registro conciso y versionado si la decisión es limitada. Lo importante es que otra persona pueda inspeccionar la proposición, la población, el método, el resultado, el límite y la decisión. El tamaño del archivo no determina la calidad del razonamiento. Un registro breve puede ser riguroso. Una presentación extensa puede ser en su mayor parte aire.
El cambio convierte la evidencia de ayer en una pregunta
Todo resultado de evaluación tiene una fecha, incluso cuando la fecha está oculta. Los modelos cambian. Las indicaciones cambian. Las fuentes de datos cambian. Un formulario anterior gana un campo. Un proveedor modifica una política. Un equipo traslada un servicio a otro entorno. Un nuevo grupo comienza a usar el sistema. Una métrica se calcula tras un proceso de revisión modificado. Cada cambio puede alterar la proposición que la evidencia anterior respaldaba.
La respuesta correcta no es volver a ejecutar todas las pruebas tras cada edición. Es definir qué cambios son materiales para qué afirmaciones. Un cambio de color puede no afectar a la calibración de probabilidades. Un nuevo canal de entrada puede afectarla. Una política de etiquetas revisada puede alterar la definición del resultado. Una nueva versión del modelo puede cambiar tanto el rendimiento como la interpretación de sus puntuaciones. Un cambio en la autoridad otorgada al sistema puede invalidar una regla de decisión aunque el modelo siga siendo idéntico byte a byte. El plan de pruebas debe hacer visibles estas relaciones antes de que un lanzamiento resulte conveniente.
El artículo 9 del Reglamento de IA describe un proceso continuo e iterativo de gestión de riesgos para los sistemas de alto riesgo a lo largo de su ciclo de vida. El proceso incluye identificar y analizar los riesgos conocidos y razonablemente previsibles, estimar y evaluar los riesgos cuando el sistema se utiliza según lo previsto y en condiciones de uso indebido razonablemente previsible, y adoptar medidas de gestión de riesgos. El punto para la evaluación es directo: la evidencia no es una ceremonia única en el momento del lanzamiento. Pertenece a un sistema operativo de revisión, cambio y respuesta.
Supervisar no significa recopilar todas las señales disponibles y esperar a que un patrón se presente por sí solo. Significa decidir qué observación permitiría reabrir una reclamación. Una comprobación de calibración puede programarse por periodo, volumen o cambio en la mezcla de entradas. Un umbral puede revisarse cuando la presión de la cola altera la calidad de la supervisión humana. Un cambio en la fuente puede suspender un uso hasta que se repita la prueba pertinente. Un plan de supervisión serio indica qué se observa, quién lo observa, con respecto a qué referencia y qué acción se deriva.
Esto exige más que una ficha de modelo archivada el día de la contratación, pero también resulta más útil. Un documento estático puede conservar lo que se afirmó. Un registro de evidencia vivo puede mostrar si la afirmación sigue teniendo cabida. Para un sistema probabilístico, esa diferencia es la diferencia entre saber que la puntuación existió y saber si sigue significando lo que el servicio cree que significa.
Los registros permiten que un lector posterior discrepe adecuadamente
La evidencia necesita memoria. Un revisor posterior no puede evaluar una reclamación a partir de una captura de pantalla de una puntuación y el recuerdo de la reunión. Necesita el objeto versionado: la pregunta, las condiciones de entrada, el método de prueba u observación, el resultado, las exclusiones, la incertidumbre, la decisión y el responsable. También puede necesitar saber qué no se capturó. Un registro que hace visibles sus puntos ciegos es más útil que un registro de apariencia perfecta que deja el estado del sistema a la especulación.
Para los sistemas de IA de alto riesgo, el Reglamento de IA exige el registro automático de eventos durante toda la vida útil del sistema, con capacidades de registro adecuadas a la finalidad prevista y útiles para identificar riesgos, respaldar la vigilancia posterior a la comercialización y supervisar el funcionamiento. También exige que se elabore documentación técnica antes de que el sistema se comercialice y que se mantenga actualizada. Estos requisitos no son meramente una invitación a conservar más registros. Son una invitación a hacer que los registros sean inteligibles en relación con un sistema, una finalidad y una decisión.
La trazabilidad es especialmente importante cuando una persona interpreta la probabilidad. Si un revisor ve una puntuación, el registro de evidencia debe permitir reconstruir a qué estaba vinculada esa puntuación, cómo se presentó, qué datos o fuentes estaban dentro del alcance, qué decidió el revisor y si se produjo una corrección posterior. Sin esa cadena, un equipo puede saber que un resultado fue incorrecto, pero no si el problema residía en la entrada, el modelo, la interfaz, la regla de decisión o el proceso humano que lo rodeaba.
En Dweve, AION es un ejemplo pequeño y pertinente del principio general, no una afirmación de que la evidencia pueda reducirse a criptografía. Su descripción pública indica que un productor puede emitir un certificado tipado junto con un resultado y que AION verifica el certificado de forma independiente frente a las premisas originales. Ese tipo de registro verificable puede reforzar una proposición limitada sobre si un resultado se deriva de premisas registradas. No demuestra que las premisas fueran adecuadas, que la tarea fuera justa o que el uso fuera apropiado. La evidencia necesita tanto verificación como juicio.
Conviene conservar esa limitación porque evita un error categórico habitual. Una traza perfectamente conservada puede mostrar lo que ocurrió. No puede convertir una pregunta mal planteada en una buena. Una decisión reproducible puede seguir siendo una decisión que nunca debería haberse automatizado. El registro debe ayudar a un lector posterior a plantear ambas preguntas, no a responder prematuramente la segunda.
La confianza puede ser honesta sin ser útil
Una probabilidad bien calibrada puede seguir siendo poco útil. Puede ser demasiado amplia para separar los casos que necesitan un tratamiento distinto. Puede llegar demasiado tarde para influir en la decisión. Puede estar ligada a un resultado que no es accionable. Puede ser tan incierta que todos los casos exijan la misma revisión. No son fallos de honestidad. Son límites de utilidad, y conviene admitirlos pronto en lugar de descubrirlos después de haber construido un flujo de trabajo en torno a la puntuación.
Por el contrario, un sistema útil no necesita fingir certeza. Una señal modesta puede mejorar la organización del trabajo si tiene un propósito acotado y una vía de revisión clara. Puede ayudar a un operador a ver qué casos merecen otra comprobación de fuentes. Puede seleccionar un conjunto pequeño para el aseguramiento de la calidad. Puede sacar a la luz un conflicto entre registros. En esos usos, el requisito de evidencia se refiere a si la señal mejora el proceso de decisión concreto sin introducir errores nuevos o dependencias inaceptables. La señal no necesita convertirse en un oráculo para ganarse un lugar.
Por eso el propósito previsto debe controlar la evaluación. Los Principios de IA de la OCDE piden información significativa sobre las capacidades y limitaciones de los sistemas, y trazabilidad en relación con los conjuntos de datos, los procesos y las decisiones, de modo que los resultados puedan analizarse y las consultas responderse. Los principios también piden una supervisión y una agencia humana adecuadas. La implicación práctica no es que toda interfaz necesite mostrar una probabilidad. Es que la evidencia y la explicación de un sistema deben ajustarse a la persona y a la decisión afectadas por él.
No hay premio por exponer un valor de incertidumbre que el usuario no puede interpretar ni aprovechar. Un número sin una vía de decisión puede crear el teatro de la transparencia. Da a la gente algo a lo que señalar y ninguna forma de cuestionarlo. Mejor mostrar el límite pertinente en lenguaje claro, como esta sugerencia está fuera de la categoría validada, o este resultado requiere revisión porque la evidencia disponible es incompleta. La presentación adecuada sigue al control operativo, no al revés.
Por la misma razón, una puntuación de confianza no debe tratarse como una medida de valor moral, credibilidad o derecho. Es una declaración técnica con un contrato probatorio limitado. Puede ayudar a un proceso. No debe convertirse en una clasificación social vaga porque su forma numérica la haga parecer concluyente.
La organización es dueña de la inferencia
Los proveedores pueden aportar modelos, documentación, puntuaciones y resultados de pruebas. No pueden apropiarse en silencio del significado de una decisión tomada en el servicio de otra persona. La organización que conecta un resultado probabilístico con una acción debe decidir en qué proposición se apoya, qué población importa, qué umbral es aceptable, quién revisa las excepciones, qué registros se conservan y cuándo ha caducado la evidencia. Los contratos pueden asignar tareas. No eliminan la necesidad de juicio.
Esto se hace visible en la contratación. Un comprador debería pedir a un posible proveedor no solo una métrica destacada, sino la pregunta de evaluación, la población, las etiquetas, las exclusiones, las versiones, la variación, el método de calibración si se hace una afirmación de probabilidad, los límites conocidos y la política de cambios. La cuestión no es exigir una divulgación que el proveedor no pueda proporcionar legalmente. Se trata de establecer si el comprador puede comprender el límite de la afirmación lo bastante bien como para usarla con responsabilidad en un contexto operativo europeo.
La respuesta puede ser a veces que la evidencia no es adecuada para el uso previsto. Eso no es un proceso de contratación fallido. Es el proceso de contratación haciendo su trabajo real antes de que la organización se haya vuelto dependiente de una puntuación inexplicada. Un uso más pequeño e inspeccionable puede seguir siendo posible. Otro proveedor puede ser adecuado. O la decisión puede permanecer humana porque la evidencia y la vía de corrección no son lo bastante sólidas para justificar la automatización. Decir que no forma parte de la disciplina de la evidencia.
La evidencia también necesita un propietario designado después del lanzamiento. Alguien debe ser responsable de comprobar si la población ha cambiado, si las revisiones revelan un nuevo patrón de errores, si un umbral sigue ajustándose a la carga de trabajo, si los registros pueden interpretarse y si un cambio desencadena una reevaluación. El propietario no tiene que ejecutar personalmente todas las pruebas. Pero si ningún rol es dueño de la inferencia, el sistema adquirirá gradualmente autoridad por costumbre. La costumbre es un mal sustituto de un registro de decisiones.
La parte más difícil suele ser cultural. Los equipos están acostumbrados a presentar los modelos exitosos como productos y los modelos fallidos como investigación. La evidencia probabilística les pide que conserven la ambigüedad intermedia: útil, limitada, supervisada y aún no autorizada para convertirse en más de lo que la evidencia respalda. Eso puede sonar menos emocionante. Es más duradero.
Qué contiene un registro de evidencia proporcionado
El registro adecuado depende del uso. Una ayuda de redacción utilizada por un autor tiene consecuencias diferentes de un sistema que influye en el acceso a un servicio público. Aun así, un registro proporcionado tiene una forma reconocible. Identifica la afirmación y el propósito previsto. Identifica el modelo, la configuración y el flujo de trabajo circundante. Define el resultado y la población utilizados para evaluar la afirmación. Conserva el método, el resultado y los límites significativos. Identifica la regla de decisión, el propietario, la vía de revisión y los desencadenantes de cambio. Cada campo ofrece a un lector posterior un punto de partida.
El registro debe distinguir la medición de la interpretación. Una observación medida podría decir que, en un conjunto de datos y un período especificados, un conjunto declarado de puntuaciones se correspondió con los resultados observados dentro de un rango descrito. Una interpretación podría decir que esto respalda su uso como señal de ordenación de revisiones bajo controles especificados. Una decisión podría decir que el sistema puede usarse para ese propósito hasta que se produzca un desencadenante de cambio declarado. Poner las tres frases bajo un encabezado llamado rendimiento solo es eficiente si nadie necesita nunca cuestionar el razonamiento.
También debería hacer utilizables las incógnitas. Tal vez las etiquetas llegan con retraso. Tal vez un grupo lingüístico pequeño no tiene suficientes casos para una evaluación de calibración estable. Tal vez el despliegue es nuevo y todavía no hay evidencia operativa. El registro puede decirlo, imponer un límite temporal de uso, organizar más observación o mantener una vía humana. Fingir que la incógnita está resuelta porque un modelo produjo un número solo convierte la incertidumbre en un pasivo sin documentar.
La disciplina visual es útil aquí. Dibuje la cadena desde la entrada hasta la puntuación, desde la puntuación hasta la explicación mostrada, desde la explicación hasta la acción humana, y desde la acción hasta el resultado observado y la corrección. Dibuje dónde se captura el estado, dónde se pierde y dónde una persona puede detener o revertir la ruta. Si el equipo no puede dibujar la ruta, es poco probable que pueda evaluarla. Los diagramas no sustituyen a la evidencia. Evitan que la evidencia se asigne a la parte equivocada del sistema.
Por encima de todo, anote lo que el registro no establece. Puede que no establezca causalidad. Puede que no establezca equidad en todos los grupos. Puede que no establezca el comportamiento tras un cambio de proveedor. Puede que no establezca la idoneidad para una acción de mayor consecuencia. Estas no-afirmaciones no son una disculpa. Son lo que impide que una evaluación acotada se use como autorización universal.
La evidencia se gana el derecho a seguir siendo incierta
Existe la tentación de pensar que el objetivo de la evaluación es eliminar la incertidumbre. A menudo, el mejor objetivo es localizarla. Un sistema probabilístico no es defectuoso porque no pueda convertir cada caso en una certeza. Se vuelve peligroso cuando la organización trata la incertidumbre como un detalle técnico privado mientras concede al resultado autoridad pública. El trabajo consiste en decidir qué incertidumbre es tolerable, visible y recuperable para el propósito en cuestión.
Esa decisión debería ser más exigente a medida que aumentan las consecuencias. Una sugerencia de bajo riesgo puede necesitar un alcance claro, una limitación visible y una corrección fácil. Un sistema que influye en derechos, seguridad, acceso u oportunidad material necesita evidencia más sólida sobre el proceso completo, una supervisión más cuidadosa, autoridad humana significativa y una vía para impugnar y remediar. La puntuación del modelo no determina ese estándar por sí sola. El efecto de actuar sobre ella sí lo hace.
Una sola ejecución exitosa puede seguir mereciendo la pena conservarla. Puede ser el primer espécimen de un registro útil. Puede revelar una capacidad, un modo de fallo o una pregunta que merece una evaluación adecuada. Pero debería seguir siendo un espécimen hasta que la organización haya probado la proposición en la que quiere confiar. La distancia entre esas dos cosas es donde vive la ingeniería responsable.
Así que la respuesta a qué cuenta como evidencia cuando la máquina es probabilística no es una puntuación, un gráfico o una etiqueta de cumplimiento. Es un argumento acotado: este resultado, para esta pregunta, en esta población y período, bajo estas condiciones, se ha observado de esta manera; esto es lo que podemos inferir; esto es lo que no podemos inferir; y esta es la acción que estamos, o no estamos, dispuestos a dejar que cambie. Ese argumento no es glamuroso. Es inspeccionable, lo cual es mejor.