Evidencia antes de adjetivo: cómo defender claims sobre sistemas de IA

“Seguro”, “confiable”, “auditable”, “autónomo” y “de clase mundial” parecen resumir madurez. Sin embargo, sin una pregunta verificable, estos adjetivos simplemente trasladan el trabajo al lector: ¿seguro contra qué amenaza, confiable en qué tarea, auditable por quién, autónomo para hacer qué?

Un claim responsable no intenta eliminar toda incertidumbre. Informa exactamente qué se observó, sobre qué objeto, mediante qué mecanismo, bajo qué límites y hasta cuándo la evidencia sigue siendo válida.

Este artículo propone una gramática práctica para transformar la confianza en el lenguaje en confianza inspeccionable.

Resumen ejecutivo

La Provenance es información verificable sobre dónde, cuándo y cómo se produjo un artefacto. un especificación SLSA Organiza niveles y formatos de attestation para aumentar las garantías de la cadena de suministro. Esto fortalece el origen y la integridad del proceso declarado, pero no prueba la corrección semántica del artefacto. [R2-C2]

Del mismo modo, un escáner, una prueba, una evaluación, una revisión o una auditoría examinan propiedades específicas. El claim defendible necesita vincular subject → propiedad → mecanismo → evidencia → verificador → validez → límite de inferencia. Si falta algún eslabón, el adjetivo debe disminuir en fuerza.

El objetivo no es escribir más descargos de responsabilidad. Se trata de permitir que el cliente, el ingeniero, el auditor o la junta directiva comprendan lo que pueden decidir sin reconstruir toda la historia.

La anatomía de un claim

Considere: “La release es segura”. La frase no identifica objeto, amenaza, control o verificador. Una release más defendible sería:

la imagen sha256:… fue producido por workflow release.yml en el constructor aprobado, firmó la provenance vinculada al commit X y pasó el escáner Y sin resultados ALTOS en la política Z el 20/08. Esto no prueba la ausencia de vulnerabilidades o seguridad de runtime.

El claim se hizo más grande, pero también se volvió utilizable. Contiene:

Provenance, atestación y verificación

La Provenance describe la historia de producción relevante. La atestación es una declaración autenticada sobre un subject. La verificación compara esta declaración y su artefacto con las expectativas y las raíces de la confianza.

Las tres cosas no son sinónimas:

• la provenance sin firmar puede ayudar al diagnóstico pero ofrece garantía limitada;
• la attestation firmada por una identidad que no es de confianza conserva una declaración que usted no acepta;
• una firma válida con un subject incorrecto autentica el enlace incorrecto;
• la provenance correcta no indica que la regla comercial sea correcta;
• la comprobación sin una política explícita sólo puede confirmar la estructura.

SLSA recomienda vincular la provenance del artefacto y verificar el subject, la firma, el constructor y los parámetros según las expectativas. Aún así, el límite canónico de FORGE permanece: la atestación prueba la cadena declarada, no la corrección semántica. [R2-C2]

Cinco clases de evidencia

Prueba de intención

Los criterios de especificación, ADR, emisión y aceptación muestran lo que debería suceder. Son esenciales, pero no demuestran ejecución.

Prueba de ejecución

Los registros, traces, diffs y receipts muestran las acciones observadas. Sin identidad ni vinculación, pueden pertenecer a otro subject o contexto.

Prueba de propiedad

Las pruebas, escáneres y evaluaciones verifican una propiedad bajo un método. Su poder termina en la cobertura y validez de ese método.

Evidencia de provenance

Los Digests, las firmas, las attestations y el historial vinculan el artefacto, el origen y el proceso. No reemplazan la evidencia de comportamiento.

Evidencia del resultado

La aceptación del cliente, la calidad percibida, los incidentes y las métricas de flujo muestran efecto. Los resultados sin causalidad o base de referencia aún requieren cautela al atribuir el cambio a la IA.

Un claim fuerte combina las clases necesarias, no todas por ritual.

El verificador es parte del claim.

“Revisado” no dice quién lo revisó, con qué criterios o con qué independencia. El mismo equipo que produce el artefacto puede realizar una valiosa autoevaluación; el error es presentarlo como una garantía independiente.

Declarar el modo:

• verificación automática determinista;
• evaluación por modelo;
• revisión de autor humano;
• revisión por un especialista distinto del autor;
• auditoría independiente con alcance y contrato;
• atestación de la plataforma que realizó el proceso.

La independencia no es un sentimiento. Es una propiedad de identidad, autoridad, incentivo y acceso a la evidencia.

Validez: la evidencia también envejece

Un informe pertenece a una versión, un entorno, una política y una fecha. Después de cambiar el modelo, el prompt, la herramienta, la dependencia, los datos o la autoridad, es posible que parte de la evidencia ya no represente el sistema.

Cada claim debe definir eventos de vencimiento:

• nuevo subject o commit;
• cambio de configuración del material;
• fuente externa actualizada o eliminada;
• madurez temporal;
• incidente que contradice la conclusión;
• descubrimiento de falla en el punto de referencia o verificador.

La corrección no debe eliminar el claim anterior. Debe registrar una nueva versión, el motivo y el alcance.

El paquete mínimo de pruebas

Para una decisión de lanzamiento, un paquete lean podría contener:

1. subject y digest;
2. especificaciones y criterios aceptados;
3. políticas aplicables;
4. resultados de gates vinculadas al mismo subject;
5. provenance e identidad del constructor;
6. excepciones con titularidad y caducidad;
7. decisión de aceptación nominal;
8. claims públicas con límite de inferencia;
9. camino de corrección o retirada.

El paquete no es un archivo enorme. Es un índice verificable de evidencia que ya existe.

Redacción de claims públicas

Intercambiar:

• “completamente seguro” ya que “pasó los controles X e Y en el alcance Z; los riesgos A y B permanecen”;
• “validado” por “evaluado en el banco V, versión N, con resultado R”;
• “auditable” mediante “las acciones A–D preservan el subject, el actor, la marca de tiempo y el receipt durante 90 días”;
• “autónomo” como “puede realizar operaciones O1/O2 en la lista de permitidos, con presupuesto y revocación”;
• “clase mundial” por una referencia comparable o eliminar el adjetivo.

La precisión no reduce la fuerza comercial. Permite que la confianza sobreviva a la primera pregunta técnica.

Una prueba de cinco minutos

Al revisar una página, presentación o informe, resalte cada adjetivo confiable y pregunte:

1. ¿Cuál es el subject?
2. ¿Qué propiedad observable respalda la palabra?
3. ¿Dónde está la evidencia?
4. ¿Quién comprobó y con qué independencia?
5. ¿Qué no permite concluir la sentencia?

Si las respuestas no caben en unas pocas líneas, el claim aún está por encima de la evidencia.

Lo que este artículo prueba y lo que no prueba

La especificación SLSA y el paquete canónico respaldan la función de provenance y su separación de la corrección semántica. [R2-C2] La gramática de claims y el paquete de pruebas son resúmenes operativos de FORGE respaldados por sus controles, conformidad y contratos de aseguramiento.

Ningún paquete de evidencia demuestra la ausencia absoluta de riesgo. Una attestation puede ser válida y la póliza insuficiente. Una auditoría independiente puede tener un alcance limitado. El objetivo es hacer visibles los límites y las decisiones asignables, no producir una certeza total.

Conclusión

La confianza comienza cuando termina el adjetivo y se pueden inspeccionar las pruebas.

Un claim defendible fija el subject, nombra la propiedad, muestra el mecanismo, preserva la evidencia, identifica al verificador y limita la validez y la inferencia. Este contrato permite decir “aún no lo sabemos” sin paralizar el trabajo y decir “está listo” sin depender únicamente de la reputación.

Lectura anterior: Autonomía proporcional al riesgo. Próxima lectura: *El agente no puede ser su propio auditor*, el 22/08 en Trustyu Forge.