Prevención de fuga de datos de IA: cómo evitar que se escapen datos confidenciales a través de indicaciones, RAG, memoria y agentes

Introducción

Los datos confidenciales no suelen dejar a un sistema de IA con un drama operístico. No derriba la puerta de una patada, no roba un auto deportivo y desaparece en la noche mientras suenan las alarmas. Lo más frecuente es que pasee silenciosamente, escondido dentro de una respuesta inocente, un fragmento de documento recuperado, el resultado de una herramienta, una línea de registro detallada o un resumen alegre generado por un modelo al que simplemente se le dio demasiado acceso y poca supervisión.

Esto es lo primero que vale la pena decir claramente. La fuga de datos de IA no es un problema de ciencia ficción. Es un problema de ingeniería y, como la mayoría de los problemas de ingeniería, crece en la brecha entre lo que la gente supone que hace un sistema y lo que realmente se le permite hacer. Un equipo construye un copiloto para la documentación interna. Funciona maravillosamente. Luego, alguien apunta a una fuente de datos más amplia, mantiene los mismos permisos de usuario, agrega memoria, incorpora algunas herramientas y, de repente, el sistema no se limita a resumir texto inofensivo. Es deambular por un almacén de material privado con la confianza de un ladrón educado.

El peligro no es que el modelo sea malo. El modelo no es malo. El modelo es obediente de la peor manera posible. Mezclará instrucciones, contexto, texto recuperado, indicaciones ocultas, memoria obsoleta y resultados de herramientas en una única sopa funcional y luego producirá algo que suene útil. Si la arquitectura que lo rodea es descuidada, la ayuda se vuelve compartida en exceso. Si los límites de los datos son débiles, la conveniencia se convierte en exfiltración. Y si el equipo confía más en la redacción inmediata que en el diseño del sistema, la historia termina como terminan muchas historias evitables: con sorpresa, vergüenza y una reunión que nadie quería.

Este artículo trata sobre cómo prevenir ese resultado. Analizaremos las verdaderas fugas en los sistemas de IA modernos, por qué fallan las ingenuas defensas, qué controles funcionan realmente y cómo construir una puerta de enlace pequeña pero útil que un equipo técnico pueda ejecutar y ampliar. El tono aquí es práctico a propósito. La cuestión no es parecer prudente. El objetivo es ayudarlo a implementar un sistema de inteligencia artificial que no entregue sus datos a la persona equivocada solo porque alguien escribió un mensaje entusiasta.

Por qué las fugas de IA ocurren de manera tan común

Las aplicaciones tradicionales suelen separar bastante bien los roles. La entrada llega a través de un lugar, la lógica empresarial reside en otro lugar y los permisos se aplican mediante rutas de código explícitas. Los sistemas de inteligencia artificial desdibujan esos límites. El lenguaje natural se convierte al mismo tiempo en un plano de entrada y de control. El conocimiento recuperado se convierte a la vez en evidencia y superficie de ataque. Las llamadas a herramientas se convierten tanto en capacidad como en exposición. Incluso la memoria, que suena inofensiva en las diapositivas de los productos, puede convertirse en una fuga lenta si nadie es disciplinado respecto de lo que se almacena y durante cuánto tiempo.

Esta es la razón por la que los equipos de productos ordinarios subestiman el problema. Creen que están integrando un modelo en un flujo de trabajo. En realidad, están introduciendo una capa de middleware probabilística que felizmente recombina datos de múltiples zonas de confianza. Si el mensaje del sistema dice "nunca reveles secretos", suena respetable. Tampoco cambia el hecho subyacente de que el modelo aún puede ver esos secretos, razonar sobre ellos y ser manipulado para presentarlos en una forma que los diseñadores no anticiparon.

La guía de Microsoft para proteger las aplicaciones empresariales de IA plantea este punto en un lenguaje corporativo sobrio: la fuga de datos, la inyección rápida y las brechas de gobernanza ya se encuentran entre las principales preocupaciones que enfrentan las organizaciones al implementar la IA. El documento es cortés, pero el mensaje es contundente. Si la IA tiene un acceso amplio y una supervisión débil, la información sensible se escapa. Una vez que vea eso, la pregunta correcta ya no es "¿Cómo hacemos que el mensaje sea más estricto?" La pregunta correcta es "¿Por qué el modelo está en condiciones de ver este material y qué control falló incluso antes de que se escribiera el mensaje?"

Ese cambio de mentalidad es importante. La seguridad madura de la IA comienza antes de que el modelo toque el primer token. Comienza con la clasificación de datos, los límites de recuperación, el control de acceso, la disciplina de registro y la autorización de herramientas. En otras palabras, la prevención de la fuga de datos de IA consiste principalmente en ingeniería de sistemas que lleva una insignia de IA.

Las verdaderas superficies de fuga

Es útil dejar de hablar del “sistema de IA” como si fuera una sola caja. Las fugas generalmente ocurren a través de una de cinco rutas, y cada ruta tiene su propio modo de falla.

El primer camino es el límite inmediato. Los equipos a menudo se preocupan por las indicaciones de los usuarios y olvidan que las indicaciones son simplemente una fuente de instrucciones entre varias. Un modelo también puede ingerir instrucciones ocultas del sistema, documentos recuperados, historial de chat resumido y datos de herramientas externas. Si alguna de esas fuentes contiene contenido contradictorio o demasiado amplio, el límite inmediato ya está comprometido. El trabajo de OWASP sobre los riesgos de las aplicaciones LLM ha sido útil precisamente porque obliga a los equipos a dejar de tratar la inyección rápida como un truco de fiesta y comenzar a tratarla como un problema del plano de control.

El segundo camino es la recuperación. La generación de recuperación aumentada parece ordenada en los diagramas de arquitectura. Hay un índice de vector, una consulta, un paso de clasificación y algunos fragmentos aparecen en la ventana de contexto. Eso parece controlado hasta que recuerdas que esos fragmentos pueden contener información del inquilino equivocado, permisos obsoletos, documentos envenenados, exportaciones no revisadas o texto que contiene instrucciones ocultas para el modelo. La recuperación es a menudo la superficie de fuga más subestimada porque no es dramática. Se siente como una búsqueda. Pero la búsqueda con una capa generativa encima puede convertir muy rápidamente un error de indexación en un evento de divulgación.

El tercer camino es la memoria. A los equipos de producto les encanta la memoria porque hace que el asistente se sienta menos rígido. A los equipos de seguridad les suele gustar menos porque la memoria suele crecer por accidente. Quizás el caché de una sesión se convierta en memoria a largo plazo. Tal vez un almacén de resúmenes interno comience a retener detalles por más tiempo del previsto. Quizás la información de identificación personal se conserve en una característica conveniente que nunca fue diseñada para cargas de trabajo sensibles. La memoria es donde las ideas amigables de UX se convierten silenciosamente en problemas de políticas de retención.

El cuarto camino es el uso de herramientas. Un modelo que puede llamar a un sistema de tickets, CRM, repositorio de código, calendario, puerta de enlace SQL o API interna ya no es solo un motor de texto. Es un sistema de acción. Eso puede ser productivo. También significa que el exceso de permisos se vuelve mucho más caro. El trabajo reciente del NIST en torno a la identidad y autorización de software y agentes de IA es valioso aquí porque aborda el punto que muchos equipos intentan omitir: cuando un sistema de IA puede actuar, la identidad y la autorización dejan de ser buenos temas de arquitectura y se convierten en puntos de control centrales.

El quinto camino es la salida y la telemetría. Incluso si la recuperación, la memoria y las herramientas están razonablemente bien controladas, el sistema aún puede filtrar respuestas, seguimientos, registros de depuración, conjuntos de datos de evaluadores, paneles de análisis y transcripciones de chat copiadas. Los equipos suelen decir "no exponemos secretos en la interfaz de usuario", mientras olvidan que el mismo contenido se almacena en registros, seguimientos, exportaciones de soporte o conjuntos de repeticiones del equipo rojo. Una fuga sigue siendo una fuga si ocurre en la pila de observabilidad en lugar de en la burbuja del chatbot.

Una vez que estas cinco superficies son visibles, el problema se vuelve menos místico. No pretendemos hacer un modelo de lenguaje moralmente puro. Estamos diseñando un sistema en el que ninguna decisión descuidada abre todas las puertas a la vez.

Por qué fracasan las defensas ingenuas

Hay varias defensas que suenan tranquilizadoras en las diapositivas y decepcionan mucho en los sistemas reales.

La primera defensa débil es el sistema de aviso severo. Decirle a la modelo que no revele información confidencial es mejor que no decir nada, así como bloquear una bicicleta con una cuerda es mejor que dejarla en la calle con una nota que diga “por favor, no lo hagas”. Pero un mensaje no es un límite de permiso. No es una política de minimización de datos. No limita la recuperación retroactivamente. Eso no impide que el modelo vea un secreto en contexto. Simplemente intenta persuadir al modelo para que se comporte después de que ya se hayan creado las condiciones peligrosas.

La segunda defensa débil es el optimismo de los proveedores. Los equipos suponen que el proveedor tiene barreras de seguridad, por lo que el problema se ha subcontratado. Ésta es una fantasía reconfortante. Las protecciones de proveedores son útiles, pero no conocen su modelo de inquilino, su taxonomía de documentos internos, sus obligaciones de retención, sus puntos finales de administración ocultos o su pequeño y extraño atajo de middleware de hace tres trimestres que todavía inyecta demasiado contexto en el modelo. Las funciones de seguridad administradas pueden reducir el riesgo, pero no pueden reemplazar su propia arquitectura.

La tercera defensa débil es "confiamos en nuestros empleados". Por supuesto que confías en tus empleados. Ese no es el punto. La gente toma decisiones rápidas bajo presión. La discusión de Microsoft sobre la IA en la sombra y el intercambio excesivo es útil porque menciona la incómoda verdad: los buenos empleados aún pueden poner información confidencial en el modelo incorrecto, conectar un modelo aprobado a la fuente de datos incorrecta o asumir que la transcripción de un chat es efímera cuando no lo es. La confianza en las personas no sustituye a los límites de los sistemas.

La cuarta defensa débil es activar algunos filtros sólo en el momento de la salida. El filtrado de resultados es importante, pero es la última red, no la base. Si el modelo ve demasiado, recupera demasiado, recuerda demasiado o puede llamar a la herramienta incorrecta, entonces el filtrado de salida intenta trapear el piso mientras la tubería aún está rota.

El patrón aquí es simple. Las defensas débiles piden al modelo que se comporte. Las defensas fuertes reducen lo que el modelo puede ver, recordar, recuperar o llamar en primer lugar.

Construya el oleoducto como si el modelo fuera curioso y descuidado

El modelo mental más limpio es este: trate al modelo como curioso, capaz, rápido y no del todo confiable en los límites. Eso no significa que el modelo sea malicioso. Significa que no se debe confiar en el modelo con un juicio implícito amplio sobre lo que es seguro revelar.

Desde ese punto de vista, un proceso de IA más seguro comienza con la clasificación de los datos. No todos los documentos deberían ser igualmente recuperables. No todos los usuarios deberían poder consultar la misma fuente. No todas las clases de datos deberían estar disponibles para el mismo modo de asistente. Si su capa de IA se encuentra en la cima de un pantano de datos donde las clasificaciones son vagas y los permisos se heredan de manera descuidada, todavía no tiene un problema de IA. Tienes un problema de almacenamiento e identidad al usar maquillaje de IA.

Después de la clasificación viene la política de recuperación. Los sistemas RAG no deberían simplemente buscar "los K fragmentos más relevantes". Deben recuperar los fragmentos K principales que sean relevantes, correctos para el inquilino, correctos para los permisos, correctos para la actualización y seguros para la tarea actual. Eso suena como trabajo extra porque es trabajo extra. Pero es más barato que explicarle a un cliente por qué la convención de nomenclatura interna de un cliente apareció en la respuesta supuestamente privada de otro cliente.

Luego viene la autorización de herramientas. Un modelo no debería recibir un cinturón de herramientas ancho y mágico. Debería recibir un conjunto reducido de herramientas cuyos permisos se limiten a la tarea, el usuario, el inquilino y el estado actual del flujo de trabajo. Las llamadas a herramientas también deberían ser observables. Si un modelo puede buscar registros, generar exportaciones, escribir en sistemas o desencadenar flujos de trabajo, el rastro de acción debe ser inspeccionable por personas que no escribieron la demostración original.

La memoria necesita la misma disciplina. Mantenga breve el contexto a corto plazo. Mantenga explícita la memoria a largo plazo. Proporcione etiquetas, vidas útiles y rutas de eliminación a los recuerdos almacenados. Decida qué categorías de información nunca se almacenan. Si no le gustaría ver un fragmento de texto en una exportación de soporte, no permita que se convierta en un recuerdo duradero simplemente porque alguien dijo "mejora la personalización".

Finalmente, coloque controles de salida al salir. La detección sensible de patrones, las verificaciones de políticas, las listas de permitidos estructuradas para clases de resultados de alto riesgo y la aprobación humana selectiva no son signos de desconfianza en el modelo. Son signos de madurez en el sistema.

Límites de RAG que realmente importan

RAG es a menudo el lugar donde los productos de IA pasan de ser un juguete a ser un sistema empresarial, y es exactamente por eso que merece más sospechas de las que suele tener.

El primer límite es el aislamiento de los inquilinos. Las tiendas de recuperación que mezclan inquilinos y dependen de un filtrado suave más adelante son accidentes que están a punto de ocurrir. Si los datos son realmente de alto valor, la respuesta más clara suele ser la separación física o lógica incluso antes de que comience la recuperación. La respuesta menos elegante pero aún respetable es el filtrado agresivo de metadatos que se aplica antes de entregar los resultados de la clasificación al modelo. La peor respuesta es recuperar de forma amplia, confiar en el modelo para inferir relevancia y esperar que no una los fragmentos equivocados.

El segundo límite es la confianza en los documentos. No todos los documentos indexados merecen la misma autoridad. Algunos fueron escritos por equipos internos confiables. Algunos fueron exportados desde otros sistemas. Algunos pueden ser proporcionados por el usuario. Algunos pueden estar obsoletos. Algunos pueden estar envenenados. La investigación sobre ataques de extracción de datos en sistemas de recuperación es importante aquí porque nos recuerda que la recuperación no se limita simplemente a buscar hechos. Puede importar instrucciones maliciosas y desencadenantes ocultos. Una capa de recuperación que no tiene concepto de nivel de confianza está solicitando a un motor de autocompletar muy costoso que actúe como revisor de seguridad.

El tercer límite es la higiene de los trozos. A los equipos les encanta hablar sobre el tamaño de los fragmentos, la superposición y la incorporación de modelos. Hablan con menos frecuencia sobre si el fragmento debería existir en primer lugar. ¿Contiene secretos que deberían haberse redactado antes de la indexación? ¿Incluye comentarios internos, credenciales o residuos de depuración? ¿Conserva identificadores innecesarios cuando bastarían resúmenes abstractos? Si su canalización RAG ingiere todo primero y luego plantea preguntas de seguridad, en realidad no es una canalización RAG segura. Es esperanzador.

El cuarto límite es la disciplina de las citas. Idealmente, un modelo debería saber qué partes contribuyeron a la respuesta y qué políticas permitieron que esas partes entraran en contexto. No porque las citas sean bonitas, sino porque la explicabilidad ayuda a la respuesta a incidentes. Cuando sucede algo malo, “la modelo debe haberlo visto en alguna parte” no es una frase satisfactoria.

Los agentes multiplican el radio de explosión

Los sistemas de chat simples pueden tener fugas. Los agentes pueden filtrarse y actuar.

La diferencia importa. Una vez que un modelo puede decidir qué herramienta llamar, en qué orden, con qué parámetros y sobre qué contexto recuperado, la superficie de ataque se amplía y la superficie de accidente se amplía con ella. El problema ya no es sólo “¿El asistente dirá algo que no debería?” El problema es: “¿Decidirá el asistente consultar algo que no debería, combinarlo con memoria que no debería haber conservado y entregar el resultado a un flujo de trabajo que nunca debió ejecutarse sobre esa base?”

Es por eso que la seguridad de los agentes no puede reducirse a una ingeniería rápida. El interés actual del NIST en la identidad y autorización de los agentes no es una decoración burocrática. Es un reconocimiento de que los sistemas de IA que utilizan herramientas necesitan identidad, alcance de privilegios y una lógica de aprobación que sea legible fuera del modelo mismo.

En la práctica, eso significa que algunos hábitos estrictos y pasados ​​de moda ayudan mucho. Separe las herramientas de lectura de las de escritura. Separe la recuperación de bajo riesgo de las acciones de alto riesgo. Utilice credenciales de corta duración. Realizar acciones peligrosas requiere una ruta de aprobación explícita. Registre por qué el agente creía que era necesaria una llamada de herramienta. Y no permita que el mismo token de acceso amplio flote en cada etapa del flujo de trabajo como un pasaporte real.

Un pequeño contraejemplo aclara el punto. Supongamos que un asistente interno de IA puede buscar en la base de conocimientos, leer tickets de problemas, redactar una respuesta al cliente y finalmente enviar esa respuesta. Un diseño débil permite que el mismo agente realice cada paso de principio a fin. Un diseño más sólido permite al asistente recuperar y redactar, pero requiere un paso de aprobación auditado por separado antes de enviar cualquier mensaje saliente. Ambos sistemas pueden parecer igualmente pulidos en una demostración. Sólo uno se comporta como si esperara que existiera el mundo real.

Una implementación de referencia que realmente puedes ejecutar

La mejor política es la que sobrevive al contacto con el código. Así que construyamos una pequeña puerta de enlace de Python que demuestre las ideas centrales: redactar secretos obvios del texto entrante, filtrar fragmentos recuperados por inquilino y clasificación, restringir las llamadas a herramientas a una lista de permitidos por solicitud y escanear la respuesta saliente antes de que salga.

Este no es un producto de seguridad empresarial completo y no pretende serlo. Es un esqueleto compacto que obliga a adoptar los hábitos arquitectónicos adecuados.

__CÓDIGO_0__

from __future__ import annotations

from dataclasses import dataclass
import fnmatch
import json
import re
from typing import Iterable


SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "jwt": re.compile(r"\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+\b"),
    "private_key": re.compile(r"-----BEGIN (RSA|EC|OPENSSH|DSA)? ?PRIVATE KEY-----"),
    "email": re.compile(r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I),
}


@dataclass(frozen=True)
class UserContext:
    user_id: str
    tenant_id: str
    role: str
    allowed_labels: tuple[str, ...]
    allowed_tools: tuple[str, ...]


@dataclass(frozen=True)
class Chunk:
    chunk_id: str
    tenant_id: str
    label: str
    text: str


def redact_text(text: str) -> str:
    result = text
    for label, pattern in SECRET_PATTERNS.items():
        result = pattern.sub(f"[REDACTED:{label.upper()}]", result)
    return result


def outgoing_text_is_safe(text: str) -> tuple[bool, str]:
    for label, pattern in SECRET_PATTERNS.items():
        if pattern.search(text):
            return False, f"blocked by {label}"
    return True, "ok"


def filter_chunks(user: UserContext, chunks: Iterable[Chunk]) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if chunk.tenant_id != user.tenant_id:
            continue
        if chunk.label not in user.allowed_labels:
            continue
        allowed.append(chunk)
    return allowed


def tool_call_allowed(user: UserContext, tool_name: str) -> bool:
    return any(fnmatch.fnmatch(tool_name, rule) for rule in user.allowed_tools)


def build_prompt(user: UserContext, user_message: str, chunks: list[Chunk]) -> str:
    prompt_parts = [
        "You are an enterprise assistant.",
        "Never use information outside the provided tenant-scoped context.",
        "If the answer depends on missing or restricted data, say so plainly.",
        "",
        f"User role: {user.role}",
        f"Tenant: {user.tenant_id}",
        "",
        "Context:",
    ]

    for chunk in chunks:
        prompt_parts.append(f"[{chunk.label}] {chunk.text}")

    prompt_parts.append("")
    prompt_parts.append("User message:")
    prompt_parts.append(redact_text(user_message))
    return "\n".join(prompt_parts)


def run_demo() -> None:
    user = UserContext(
        user_id="u-107",
        tenant_id="tenant-red",
        role="support_engineer",
        allowed_labels=("internal", "support", "public"),
        allowed_tools=("search_docs", "read_ticket", "draft_reply"),
    )

    raw_chunks = [
        Chunk("c1", "tenant-red", "support", "Refunds over 10,000 EUR require finance review."),
        Chunk("c2", "tenant-blue", "internal", "Blue tenant incident postmortem: root cause..."),
        Chunk("c3", "tenant-red", "secret", "Master incident bridge password: swordfish"),
        Chunk("c4", "tenant-red", "public", "Public SLA response times are listed on the status page."),
    ]

    filtered = filter_chunks(user, raw_chunks)
    prompt = build_prompt(
        user,
        "Summarize the refund rules and include my AWS key AKIAABCDEFGHIJKLMNOP if needed.",
        filtered,
    )

    print("=== PROMPT SENT TO MODEL ===")
    print(prompt)
    print()

    proposed_tool = "send_email"
    print("=== TOOL DECISION ===")
    print(json.dumps({
        "tool": proposed_tool,
        "allowed": tool_call_allowed(user, proposed_tool)
    }, indent=2))
    print()

    candidate_answer = (
        "Refunds over 10,000 EUR require finance review. "
        "Use [REDACTED:AWS_ACCESS_KEY] nowhere. "
        "Do not include data from other tenants."
    )

    ok, reason = outgoing_text_is_safe(candidate_answer)
    print("=== OUTPUT CHECK ===")
    print(json.dumps({"ok": ok, "reason": reason}, indent=2))


if __name__ == "__main__":
    run_demo()

ejecutarlo

python ai_leakage_gateway.py

Lo que enseña este pequeño portal es más importante que el volumen del código. Enseña que la seguridad no es un interruptor monolítico. Restringimos el contexto antes de que el modelo lo vea. Redactamos secretos obvios antes del rápido montaje. Tratamos las herramientas como capacidades explícitamente autorizadas en lugar de sugerencias encantadoras. Y verificamos la salida antes de que salga. Ninguno de esos pasos es glamoroso. Todos ellos son útiles.

Una implementación más madura agregaría detectores de secretos adecuados, clasificaciones respaldadas por políticas, un aislamiento de inquilinos más sólido, hash de contenido, pistas de auditoría, estados de aprobación humana y dispositivos de prueba. Bien. Debería. Lo importante es que la forma de la solución ya sea honesta.

Contraejemplos que vale la pena recordar

Ayuda mantener algunos malos patrones en la pared, porque los equipos los repiten con una creatividad deprimente.

Un mal patrón es el copiloto universal. Tiene acceso a todo porque "queremos una experiencia unificada". En la práctica, esto a menudo significa que el asistente puede ver más de lo que a cualquier humano se le permitiría ver en un solo lugar. Cuando ese sistema falla, el verdadero culpable no es el modelo. El culpable es la codicia arquitectónica.

Otro mal patrón es la demostración de “RAG seguro” que indexa silenciosamente las exportaciones sin procesar del almacenamiento compartido. La demostración parece maravillosa hasta que alguien pregunta si la tienda de vectores aplica los límites de los inquilinos en el momento de la recuperación o solo después de redactar la respuesta. Si la respuesta es vaga, el riesgo no lo es en absoluto.

Otra es la función de memoria que nadie posee. El producto cree que mejora la continuidad. La seguridad supone que será de corta duración. Legal supone que la retención se define en otro lugar. El soporte descubre seis meses después que aún pueden resurgir fragmentos antiguos. Así es como características inocentes se convierten en fallas de gobernanza.

Luego está la trampa de la tala. Los ingenieros suelen añadir trazas enriquecidas durante el desarrollo, prometen limpiarlas más tarde y nunca lo hacen. El resultado es que la interfaz de usuario del producto puede ser respetable mientras que la pila de observabilidad se convierte en un museo de material sensible. Esta es una de las vías de fuga más aburridas y una de las más comunes.

La buena ingeniería a menudo parece lo opuesto a estos errores. Parece más estrecho. Más explícito. Un poco menos mágico. Eso no es un defecto. Es una marca de sistemas que esperan sobrevivir al contacto con la realidad.

Los controles organizacionales importan más de lo que la gente quiere admitir

Existe un romance en torno a resolver todo en código, y no es del todo inmerecido. Pero la prevención de fugas de IA también es un problema disciplinario.

Los equipos necesitan una política de herramientas aprobada, no porque los documentos de políticas sean emocionantes, sino porque la IA en la sombra es real. Necesitan reglas básicas de manejo de datos para solicitudes y cargas. Necesitan una forma de decidir qué sistemas internos pueden alimentar funciones de IA y cuáles no. Necesitan rutas de revisión para casos de uso de alto riesgo. Necesitan a alguien que sea dueño de la retención. Necesitan a alguien que posea un inventario de modelos y herramientas. Y necesitan la humildad de decir: "Esta carga de trabajo aún no está lista para un acceso amplio a la IA".

Los mejores controles técnicos del mundo seguirán teniendo dificultades si la organización trata cada característica de la IA como un atajo de emergencia para la productividad. La seguridad es más fácil cuando la empresa ofrece alternativas seguras en lugar de simplemente gritar "no utilice herramientas no aprobadas". La guía de Microsoft hace esto bien. La gente evita la fricción. Si el camino seguro es miserable y el camino inseguro es rápido, el camino inseguro desarrollará seguidores leales.

Entonces sí, construye las barandillas. Pero también hacer que el flujo de trabajo seguro sea lo suficientemente utilizable para que los ingenieros y trabajadores del conocimiento no sientan que están siendo castigados por cooperar.

Laboratorio práctico: convierta la demostración en una puerta de enlace de políticas real

Si desea pasar de la teoría a algo que su propio equipo pueda tocar, este es un buen ejercicio para un fin de semana.

Comience con la puerta de enlace de Python anterior y asígnele un archivo de política real.

__CÓDIGO_0__

{
  "tenant_red": {
    "support_engineer": {
      "allowed_labels": ["public", "support", "internal"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply"]
    },
    "finance_admin": {
      "allowed_labels": ["public", "support", "internal", "finance"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply", "read_finance_record"]
    }
  }
}

Luego extienda la puerta de enlace para que:

1. los usuarios y roles se cargan desde la política en lugar de estar codificados;
2. los fragmentos de recuperación se rechazan a menos que tanto el inquilino como la etiqueta coincidan;
3. cada llamada a herramienta bloqueada se registra con un motivo;
4. las respuestas salientes que contienen cadenas con forma de secreto se ponen en cuarentena en lugar de devolverse;
5. la memoria se escribe solo para los tipos de conversación incluidos en la lista permitida.

Si lo hace honestamente, notará algo útil. El problema rápidamente deja de parecer “ingeniería rápida” y comienza a sentirse como lo que realmente es: un trabajo de integración de sistemas y seguridad con un modelo en el medio.

Tareas de prueba para entusiastas

Si desea ampliar el artículo y aprender algo real en lugar de simplemente asentir, pruebe lo siguiente:

1. Agregue una prueba de discrepancia tenant_id y demuestre que el fragmento incorrecto nunca llega al mensaje.
2. Amplíe el filtro de salida para marcar ID de clientes, referencias de tickets internos y artefactos de pago.
3. Agregue una segunda etapa que requiera aprobación humana antes de que se pueda ejecutar cualquier herramienta con capacidad de escritura.
4. Almacene la memoria a corto plazo solo durante quince minutos y luego agregue registros de eliminación y caducidad automática.
5. Cree dos indicaciones del equipo rojo: una directa, otra oculta dentro del texto recuperado, y observe qué control detecta qué falla.

Conclusión

La prevención de la fuga de datos de la IA no es una cuestión de encontrar la frase perfecta para colocar en un mensaje del sistema. Se trata de construir un sistema en el que los datos confidenciales se clasifiquen tempranamente, la recuperación tenga el alcance adecuado, la memoria esté restringida, las herramientas se autoricen de manera estricta y los resultados se verifiquen antes de que salgan del edificio.

Esto puede parecer menos glamoroso que la versión comercial de la IA. Bien. El glamour está sobrevalorado en seguridad. Los equipos que triunfan aquí suelen ser los que están dispuestos a ser precisos pasada de moda. Ellos deciden qué puede ver el modelo, qué puede hacer, qué puede recordar y qué debe ser revisado por un humano. No le piden al modelo que desarrolle una ética a través de la puntuación.

Y eso, en cierto modo, es alentador. Porque significa que la solución no es mística. Es ingeniería. Ingeniería dura a veces, sí. Ingeniería un poco molesta, sin duda. Pero sigue siendo ingeniería. Lo que significa que se puede razonar, probar, mejorar y enviar.

Si su sistema de inteligencia artificial ya está tocando información confidencial, ahora es un muy buen momento para dejar de admirar al asistente y comenzar a inspeccionar los límites que lo rodean. Ahí es donde siempre ha estado la verdadera historia.

Referencias

• NIST, Marco de gestión de riesgos de inteligencia artificial: perfil de IA generativa: https://doi.org/10.6028/NIST.AI.600-1
• NIST, Iniciativa de estándares de agentes de IA: https://www.nist.gov/caisi/ai-agent-standards-initiative
• NIST NCCoE, Identidad y autorización de agentes de software e IA: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OWASP, Top 10 para aplicaciones de LLM: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• AWS, GENSEC04-BP02: Implemente controles para protegerse contra inyecciones rápidas e intentos de jailbreak: https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec04-bp02.html
• AWS, Navegando por el panorama de seguridad de la IA generativa: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft, Guía para proteger la empresa impulsada por IA: introducción a las aplicaciones de IA: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprise-Getting-Started-with-AI-Applications.pdf
• Yupei Lv et al., PLeak: ataques de filtración rápidos contra aplicaciones de modelos de lenguaje grandes: https://arxiv.org/abs/2405.06823
• Yuxin Wen et al., Ataques de extracción de datos en generación aumentada de recuperación a través de puertas traseras: https://arxiv.org/abs/2411.01705