La pregunta más importante de arquitectura de seguridad de IA es ¿dónde está la frontera de confianza?. No "confío en X" / "no confío en Y". eso es binario y falso. La pregunta real es: ¿en qué punto del flujo dejás de tratar al dato como confiable y empezás a tratarlo como entrada que necesita validación?
Marcá cada fuente de datos con una etiqueta:
Confiable se puede meter directo. No confiable hay que etiquetar y validar antes de que cruce a otra capa.
Mensaje del usuario. Obvio. el usuario puede escribir cualquier cosa, incluyendo payloads. Tiene que entrar en el modelo dentro de <user_input> tags, después de sanitización (longitud, Unicode, scrubbing de PII).
Output del LLM. Menos obvio, pero igual de importante. El output del modelo es no confiable porque el modelo puede haber sido inyectado. Cualquier output que va a un destino con poder (tools destructivas, pantalla del usuario, próximo paso del agente) tiene que pasar por validación de output (lección 15).
Respuesta de tool externa. Pegaste contra un API de tercero. esa respuesta es texto del mundo, puede tener payload escondido. Envolvela en <tool_output> y declarala como dato, no instrucción.
Documento de RAG. Tu vector store devolvió un fragmento. ese fragmento se escribió hace meses, en otro contexto, posiblemente por alguien hostil. Mismo tratamiento: <retrieved_content>, dato no instrucción.
Config interna. Vive en tu repo. Si cambió, hubo un PR, hubo review. Esa es la única razón por la que confiás en ella.
Secreto del vault. Confiable en cuanto a contenido (lo pusiste vos, encriptado, audit-logged). Pero su destino seguro es solo la tool del lado confiable. Nunca va al contexto del modelo ni a la pantalla del usuario.
Regla de Hex: cuando dibujás la arquitectura, ponele color a las flechas. Verde = confiable. Rojo = no confiable. Cada flecha roja necesita una capa de validación antes de cruzar a un destino con poder. Si no podés explicar dónde está esa capa, no hay capa.
A la derecha: seis emisores, tres destinos. Conectá solo las flechas verdes.