Redactar el brief técnico de una aplicación LLM

El proyecto final convierte una idea en una especificación que negocio, desarrollo, seguridad y producto pueden revisar antes de construir. El objetivo es hacer visibles las decisiones que una demo suele esconder.

No necesitas diseñar todavía cada endpoint. Necesitas demostrar qué problema existe, por qué un LLM aporta valor, qué queda fuera del modelo y cómo comprobarás si la arquitectura funciona.

1. Problema, usuario y resultado

Describe:

• quién realiza la tarea;
• qué entrada recibe;
• qué resultado necesita;
• frecuencia y volumen;
• línea base actual;
• consecuencias de error;
• tiempo aceptable;
• situación que activa el proceso.

Evita frases como «crear un copiloto inteligente». Sustitúyelas por una capacidad observable: «extraer requisitos de solicitudes y preparar una propuesta para revisión en menos de X tiempo».

2. Justificación del LLM

Explica qué parte requiere interpretación o generación y qué parte no.

Separa:

• reglas;
• cálculos;
• consultas;
• búsqueda;
• generación;
• revisión humana.

Incluye una alternativa sin LLM. Si no puedes explicar qué mejora el modelo frente a reglas, búsqueda o software convencional, el caso todavía no está bien formulado.

3. Arquitectura de responsabilidades

Dibuja un flujo mínimo:

usuario → autenticación → preparación → modelo/recuperación/herramientas → validación → acción → almacenamiento → observabilidad

Para cada bloque registra responsable, entradas, salidas y fallos.

No escondas la autorización dentro del prompt. Permisos, límites y efectos pertenecen a la aplicación.

4. Entradas y contexto

Documenta:

• datos de usuario;
• documentos;
• fuentes;
• estado;
• historial;
• herramientas disponibles;
• información excluida;
• estrategia de contexto;
• tratamiento de saturación.

Indica qué contenido es sensible y por qué necesita entrar.

5. Contrato de salida

Define:

• formato;
• esquema;
• campos obligatorios;
• evidencia;
• estados desconocidos;
• validación semántica;
• reglas de negocio;
• ruta de error;
• revisión.

Una salida correcta debe poder comprobarse sin leer «lo que quiso decir» el modelo.

6. Recuperación y herramientas

Para cada mecanismo justifica por qué existe.

Si usas RAG, enlaza el corpus, permisos y evaluación. Si usas herramientas, documenta argumentos, autorización y efectos. Si mantienes estado, define persistencia y borrado.

Si la secuencia es estable, describe un workflow. Si propones autonomía dinámica, identifica qué incertidumbre justifica un agente y qué límites de iteración o acción tendrá.

7. Requisitos no funcionales

Incluye objetivos o límites para:

• latencia;
• volumen;
• disponibilidad;
• coste;
• privacidad;
• seguridad;
• observabilidad;
• recuperación ante fallos;
• retención;
• portabilidad.

No necesitas conocer todavía todos los números, pero los campos no deben quedar invisibles.

8. Evaluación

Crea un conjunto inicial de casos que represente:

• entradas normales;
• ambiguas;
• incompletas;
• adversariales;
• errores de herramienta;
• falta de permiso;
• casos críticos.

Define qué medirás y qué fallo bloquea el piloto.

NIST AI RMF propone un enfoque de gestión de riesgo basado en contexto, medición y gestión. Es un marco voluntario, no una obligación general para todas las aplicaciones, pero resulta útil como referencia para no separar calidad técnica de impacto y control.

9. Selecciona la incertidumbre principal

No construyas la aplicación completa para descubrir al final que la clasificación no funciona o que los datos no pueden utilizarse.

Identifica el supuesto más arriesgado:

• calidad del modelo;
• disponibilidad de contexto;
• tool use;
• latencia;
• privacidad;
• coste;
• integración.

Diseña un prototipo que pruebe ese supuesto con el menor trabajo posible.

10. Mantén la complejidad bajo control

Una buena arquitectura no maximiza el número de llamadas, agentes o componentes. Anthropic documenta, desde su experiencia como proveedor, que muchas implementaciones eficaces parten de patrones simples y añaden complejidad solo cuando mejora resultados. Utiliza esa idea como criterio de diseño, no como ley universal.

Pregunta por cada capa: «¿qué fallo o requisito justifica que exista?».

Ejemplo de brief resumido

Problema: solicitudes comerciales llegan en texto libre y requieren revisar requisitos antes de preparar presupuesto.

LLM: interpreta y estructura requisitos.

Código: valida catálogo, precios y fechas.

Herramienta: consulta CRM y disponibilidad.

Estado: conserva solicitud y versión de propuesta.

Salida: JSON estructurado con evidencia y review_required.

Revisión: obligatoria si faltan datos o se supera umbral comercial.

Evaluación: 100 solicitudes históricas anonimizadas, incluyendo excepciones.

Piloto: modo asistido; el sistema prepara, una persona valida.

Este resumen ya permite discutir responsabilidades sin empezar por una interfaz.

Define criterios de aceptación antes del prototipo

El brief debe declarar qué resultado permitiría continuar y qué resultado obliga a detenerse. Si el criterio se decide después de ver la demo, es fácil racionalizar cualquier salida como suficiente.

Ejemplos de criterios que deberán concretarse para el caso:

• porcentaje mínimo de casos correctamente estructurados;
• cero acciones no autorizadas en el conjunto crítico;
• límite de latencia;
• carga máxima de revisión humana;
• coste máximo por caso;
• comportamiento correcto ante datos ausentes.

No copies umbrales universales. Establécelos desde el valor y el riesgo del proceso.

Documenta decisiones y alternativas descartadas

Incluye un pequeño registro:

decisión → alternativas → criterio → evidencia → riesgo → fecha

Esto evita que una elección temporal parezca una verdad técnica permanente. También facilita revisar la arquitectura cuando aparece un nuevo modelo, cambia un requisito o el volumen crece.

Prepara el traspaso a implementación

C04 debería recibir un brief con interfaces suficientemente claras para empezar a construir sin reabrir la pregunta de negocio. Eso incluye datos de entrada, contrato de salida, mecanismos externos y casos de evaluación.

No necesita un diseño final de infraestructura, pero sí fronteras y responsabilidades que puedan convertirse en módulos de software y pruebas.

Entregable final

El brief debe incluir:

1. objetivo y alcance;
2. usuario y proceso;
3. hipótesis de valor;
4. arquitectura;
5. responsabilidades;
6. datos y permisos;
7. política de contexto;
8. salida y validaciones;
9. recuperación/herramientas/estado;
10. requisitos operativos;
11. seguridad y privacidad;
12. benchmark;
13. riesgos;
14. alternativas descartadas;
15. prototipo propuesto;
16. criterio de avance o parada;
17. decisión solicitada.

Revisión cruzada

Pide a negocio que confirme el problema y la consecuencia de error. A desarrollo, que revise interfaces y estados. A seguridad o privacidad, que revise datos y permisos. A producto, que valide experiencia y métricas.

Una decisión no está cerrada porque «la IA parece funcionar». Está cerrada cuando el equipo entiende qué debe demostrar el piloto y qué ocurrirá si no lo demuestra.

Cierre del minicurso

El fundamento de una aplicación LLM no es el prompt. Es la asignación correcta de responsabilidades.

El modelo aporta interpretación y generación. El contexto aporta información. La recuperación aporta conocimiento externo. Las herramientas conectan acciones y datos vivos. El estado conserva continuidad. El código aplica reglas y permisos. La evaluación determina si el conjunto cumple la tarea.

C04 parte de este brief para convertir esas decisiones en una aplicación implementada con APIs y código.