Desarrollar aplicaciones empresariales con LLM y APIs: arquitectura, herramientas, seguridad y operación · Módulo 4: Seguridad y evidencia

Crear pruebas, evals de aceptación y trazabilidad mínima

Quality gate de desarrollo con tests deterministas, acceptance set, smoke tests live y trazabilidad suficiente para permitir o bloquear un piloto sin duplicar la operación de C06.

Objetivo de aprendizaje

Construir una puerta de calidad reproducible que pruebe contratos, seguridad y comportamiento LLM antes del piloto y deje artefactos preparados para la operación avanzada de C06.

C04 necesita demostrar que la aplicación puede entrar en un piloto sin romper sus contratos. No necesita todavía construir el sistema completo de SLOs, monitorización continua, canary releases e incident response: esa disciplina pertenece a C06.

La frontera de esta lección es deliberada. Aquí se construye el quality gate de desarrollo: pruebas deterministas, un conjunto pequeño de casos representativos, smoke tests live y trazabilidad suficiente para reproducir un fallo.

Prueba primero lo que debe ser determinista

Gran parte de una aplicación LLM sigue siendo software convencional y debe probarse como tal.

Unitarias

  • validadores;
  • reglas de negocio;
  • transformaciones;
  • normalización de errores;
  • construcción de idempotency keys.

Integración

  • repositorios;
  • adaptador de proveedor simulado;
  • tools;
  • jobs;
  • persistencia;
  • caches.

Contrato

  • JSON Schema;
  • tool schemas;
  • eventos;
  • API pública;
  • compatibilidad entre versiones.

Seguridad

  • acceso entre tenants;
  • ID no autorizado;
  • tool denegada;
  • input malicioso;
  • secreto ausente de logs.

Un modelo variable no justifica que el resto del sistema sea ambiguo.

Construye un acceptance set pequeño

Para la capacidad LLM selecciona casos que representen el piloto previsto. No necesitas todavía el programa de evaluación de producción de C06.

Cada caso debería registrar:

  • case_id;
  • input;
  • contexto;
  • referencia o rúbrica;
  • campos críticos;
  • comportamiento prohibido;
  • riesgo;
  • resultado.

Incluye camino normal, dato ausente, caso ambiguo, falta de permiso, fallo de tool y al menos un caso adversarial relevante.

La pregunta es concreta:

«¿Esta candidata satisface el contrato que prometemos en el piloto?»

No intentes convertir este conjunto en un benchmark universal del modelo.

Separa graders deterministas y semánticos

Cuando el criterio pueda expresarse en código, usa código:

  • schema válido;
  • categoría existente;
  • recurso autorizado;
  • tool correcta;
  • efecto único;
  • estado final esperado.

Para calidad semántica puedes utilizar revisión humana o un grader asistido por modelo, pero calibra ese grader con una muestra revisada. Una puntuación automática no debe sustituir un invariante de seguridad.

Añade smoke tests live de forma explícita

Los tests normales deben ejecutarse con un proveedor falso o fixtures. Las llamadas live sirven para comprobar que la integración real sigue siendo compatible:

  • autenticación;
  • endpoint;
  • modelo disponible;
  • schema aceptado;
  • tool calling;
  • respuesta normalizable.

Ejecuta estos smoke tests como tarea opt-in o pre-release porque consumen red, cuota y pueden variar con el proveedor.

Traza lo suficiente para reproducir

Antes del piloto necesitas poder reconstruir una ejecución concreta. Conserva referencias como:

  • request_id o trace_id;
  • versión de aplicación;
  • versión de instrucciones;
  • modelo efectivo;
  • tool catalog;
  • latencia;
  • usage;
  • estado de error;
  • IDs de contexto o evidencia.

Minimiza contenido sensible. OpenTelemetry distingue traces, metrics y logs y permite propagar contexto entre componentes; puedes utilizar OTel o un mecanismo equivalente.

Esta trazabilidad de desarrollo no sustituye la observabilidad operacional de C06. Su función es responder «¿qué versión produjo este fallo y por qué camino pasó?».

Define la puerta para permitir un piloto

La release candidata debe tener criterios explícitos. Por ejemplo:

BLOCK
- cualquier acceso cross-tenant
- cualquier escritura no autorizada
- contrato estructural roto
- caso crítico fallido

REVIEW
- calidad semántica bajo objetivo
- latencia o coste por encima del presupuesto del piloto

PASS
- tests deterministas verdes
- acceptance set dentro de criterios
- smoke test live compatible
- trazabilidad disponible

Los umbrales dependen del caso. Lo importante es decidirlos antes de mirar el resultado de la candidata.

Prepara el hand-off a C06

El entregable de C04 debe poder alimentar después una disciplina de producción. Conserva:

  • tests;
  • acceptance set;
  • rúbricas;
  • manifest de versiones;
  • trazas de ejemplo;
  • resultados del piloto;
  • fallos conocidos.

C06 ampliará estos artefactos a datasets versionados, regression gates, SLOs, monitorización, canarying, incidentes y readiness.

Ejercicio

Construye el quality gate de una capacidad real:

  1. cinco tests unitarios;
  2. cinco de integración/contrato;
  3. tres de seguridad;
  4. diez casos de aceptación;
  5. un smoke test live opt-in;
  6. un manifest de versiones;
  7. un ejemplo de trace;
  8. criterios BLOCK / REVIEW / PASS.

Introduce deliberadamente una regresión de permisos y otra semántica y comprueba que el gate las distingue.

Criterio de salida

Al finalizar, debes contar con evidencia suficiente para permitir o bloquear un piloto sin convertir C04 en un curso de operación. La candidata queda probada como aplicación; C06 será la residencia de evaluación continua, observabilidad y fiabilidad en producción.