En artículos anteriores, hemos conversado sobre la implicancia en materia de ciberseguridad sobre el uso de LLM e IA, también hemos conversado sobre herramientas para robustecer la seguridad de modelos LLM, e incluso hablamos de los ataques adversariales en LLM y los diferentes métodos de defensa sobre los adversarial attacks. Hoy con el arribo de las tecnologías digitales en general la adopción de IA es del orden logarítmico y todos vemos en las organizaciones que aparece en copilots internos, buscadores corporativos, asistentes de atención, automatización documental, análisis de tickets, generación de código y resúmenes ejecutivos. El problema es que, en muchas organizaciones, la adopción va más rápido que el control.
Usar LLM puede aportar productividad real, pero también abrir una nueva superficie de exposición. Prompt injection, fuga de datos, dependencias de terceros, abuso por parte de insiders, automatizaciones mal conectadas y decisiones excesivamente confiadas en la salida del modelo son algunos de los riesgos que ya figuran entre las preocupaciones centrales de seguridad y gobernanza. Cómo evaluar riesgos en la implementación de LLM corporativos: pasos clave para un diagnóstico inicialOWASP incluye entre los riesgos principales para aplicaciones con LLM categorías como prompt injection, insecure output handling, data leakage, excessive agency y supply chain vulnerabilities.
La buena noticia es que una empresa no necesita “resolver la IA” de una sola vez para empezar bien. Lo que sí necesita es un enfoque ordenado, entender dónde están usando LLM, qué datos intervienen, qué decisiones dependen de esas respuestas y qué controles mínimos deben existir antes de escalar.
El primer error: tratar al LLM como si fuera solo otra aplicación SaaS
Muchas implementaciones arrancan con una pregunta demasiado simple: “¿Qué proveedor usamos?”. Pero el problema real no es solo el proveedor, sino el sistema completo que se construye alrededor del modelo.
Un LLM empresarial rara vez funciona aislado. Suele conectarse con bases de conocimiento, documentos internos, CRMs, ERPs, repositorios de código, correo, APIs, herramientas de tickets o flujos de automatización. En ese momento, el riesgo deja de ser puramente IA y pasa a ser riesgo operativo, de datos, de seguridad de aplicaciones y de terceros.
MITRE ATLAS define este espacio como una superficie específica de amenazas contra sistemas habilitados por IA, y su enfoque es útil justamente porque obliga a mirar más allá del modelo: datos, herramientas, integraciones, plataforma y entorno.
En otras palabras no alcanza con preguntar si el modelo “es seguro”. Hay que preguntarse qué puede ver, qué puede hacer, qué otros sistemas toca y qué impacto tendría un error o abuso.
Antes de mitigar, hay que mapear
La primera tarea práctica no es técnica: es inventariar.
En una empresa promedio, el uso de LLM suele crecer de forma desordenada. Hay equipos usando asistentes públicos, áreas de negocio probando bots con documentos sensibles, desarrolladores integrando APIs externas y proveedores metiendo capacidades “AI-powered” dentro de productos existentes. Sin un inventario mínimo, cualquier intento de control llega tarde.
Ese inventario debería responder cinco preguntas:
1. Qué casos de uso existen hoy
No solo los aprobados formalmente. También los informales o shadow AI: empleados que pegan contenido en asistentes públicos, áreas que usan plugins no revisados o equipos que activaron funciones generativas en suites corporativas.
2. Qué datos se exponen al modelo
No es lo mismo resumir políticas públicas que procesar contratos, código fuente, datos de clientes, tickets con credenciales, reportes financieros o documentación técnica interna.
3. Qué nivel de acción tiene el sistema
Un bot que solo responde consultas no tiene el mismo riesgo que uno que además crea tickets, envía correos, modifica registros o ejecuta flujos automatizados. OWASP denomina a este problema excessive agency: cuanto más puede hacer el sistema, más crítico se vuelve el control.
4. Qué dependencias externas existen
Modelo base, embeddings, vector database, plugins, librerías, gateways, repositorios de prompts, conectores y proveedores. El riesgo de supply chain no desaparece por llamarse “IA”; en muchos casos, se expande.
5. Qué impacto tendría una respuesta incorrecta o manipulada
No todo caso de uso tiene el mismo perfil. Un error en brainstorming interno no equivale a una alucinación en soporte legal, una clasificación errónea de fraude o una sugerencia insegura de código.
Sin ese mapa, la conversación sobre riesgos queda en abstracciones.
Los riesgos que más importan al empezar
No todas las organizaciones necesitan un red team de IA desde el día uno. Pero sí conviene priorizar los riesgos que aparecen con más frecuencia en despliegues tempranos.
1. Fuga de información sensible
Es el riesgo que más rápido entienden las áreas legales y de seguridad. Si empleados o aplicaciones envían información sensible al modelo sin controles adecuados, la exposición puede ocurrir antes incluso de que exista un incidente clásico.
La evaluación no debe quedarse en “el proveedor entrena o no con mis datos”. Esa pregunta importa, pero no alcanza. También hay que revisar retención, controles de acceso, segregación entre tenants, logging, exportación de conversaciones, permisos de administradores y si existen opciones contractuales o técnicas para limitar retención. En el caso de OpenAI para entornos empresariales, la compañía indica que no entrena sus modelos con datos de negocio por defecto y ofrece controles de retención para organizaciones elegibles, incluida retención cero en ciertos escenarios de API.
La lección es simple: “no entrenar con mis datos” no equivale automáticamente a “riesgo resuelto”.
2. Prompt injection
Es uno de los problemas más característicos del mundo LLM. Ocurre cuando una entrada maliciosa —en un prompt directo, un documento, una página web, un correo o una base de conocimiento— manipula el comportamiento del sistema y lo empuja a ignorar instrucciones previas, revelar datos o ejecutar acciones no previstas. OWASP lo ubica como LLM01 en su Top 10 2025.
El punto clave para una empresa es entender que el texto de entrada ya no es “solo contenido”: puede convertirse en una vía de control. Esto afecta especialmente a implementaciones RAG, asistentes conectados a documentos y agentes con herramientas.
3. Salida insegura y automatización excesiva
Cuando una respuesta del modelo alimenta otro sistema sin validación, el riesgo escala. Puede ser código que se ejecuta, SQL que se dispara, decisiones operativas que se aprueban automáticamente o mensajes que salen a clientes sin revisión.
OWASP también destaca insecure output handling como una categoría propia porque la salida del modelo no debe tratarse como confiable por defecto.
Un buen principio es pensar que toda salida del LLM es contenido no confiable hasta que pase por validación técnica o humana.
4. Dependencias y cadena de suministro
En muchos proyectos, el modelo es solo una pieza. Alrededor aparecen frameworks de agentes, plugins, proveedores de embeddings, bases vectoriales, datasets y librerías que cambian rápido. Cada componente agrega superficie de ataque y complejidad de aseguramiento. OWASP mantiene supply chain vulnerabilities entre los riesgos prioritarios de apps con LLM.
5. Alucinaciones con impacto de negocio
No toda alucinación es un incidente de seguridad, pero algunas sí pueden convertirse en uno. Una respuesta falsa que derive en una acción administrativa errónea, una mala interpretación contractual o una guía técnica peligrosa puede generar daño operativo, legal o reputacional.
Por eso NIST insiste en tratar la IA generativa como un problema de riesgo socio-técnico y no meramente tecnológico. Su perfil para GenAI propone alinear el uso con objetivos, contexto, gobernanza y controles de medición y gestión, no solo con pruebas funcionales.
Un enfoque simple para evaluar riesgo sin paralizar el negocio
Una forma práctica de empezar es clasificar cada caso de uso según cuatro ejes:
- Datos: públicos, internos, confidenciales, regulados.
- Acción: solo sugiere, recomienda, ejecuta, integra con sistemas críticos.
- Autonomía: con humano en el loop, semi-automático, autónomo.
- Impacto: bajo, medio, alto, crítico.
Con eso, la empresa puede separar rápidamente tres grupos:
Casos de bajo riesgo: Asistencia de redacción, resumen de contenido no sensible, brainstorming, transformación de texto interno no crítico.
Casos de riesgo medio: Búsqueda interna con documentos corporativos, análisis de tickets, soporte técnico asistido, ayuda al desarrollo con repositorios acotados.
Casos de alto riesgo: Procesamiento de datos sensibles, decisiones con impacto regulatorio, acciones automáticas sobre sistemas, acceso a código fuente crítico, atención al cliente con alto grado de autonomía, flujos conectados a pagos o identidad.
La clave no es prohibir todo lo que cae en la tercera categoría, sino exigir más controles antes de habilitarlo.
Qué controles mínimos conviene implementar desde el principio
Acá suele aparecer la tentación de construir un gran programa de gobierno. Pero en la práctica, la mejor estrategia inicial es un baseline corto y obligatorio.
Gobierno de datos: Definir qué tipo de información puede y no puede enviarse a sistemas LLM. Esto incluye clasificación, reglas de uso, minimización de datos, redacción/mascarado cuando aplique y separación clara entre entornos de prueba y producción.
Aprobación de casos de uso: No hace falta burocracia extrema, pero sí un proceso ligero para responder: qué problema resuelve, qué datos usa, qué herramientas toca, qué impacto tendría un error y quién es el dueño del riesgo.
Revisión de proveedor y arquitectura: Contrato, retención, uso de datos, autenticación, logging, cifrado, residencia de datos si aplica, controles administrativos, integraciones y límites de responsabilidad. En proveedores empresariales, revisar también opciones de compliance y control de claves cuando existan.
Guardrails técnicos: Filtros de entrada y salida, límites de contexto, segmentación de permisos, allowlists de herramientas, validación de respuestas estructuradas, sanitización de contenido recuperado y revisión humana para acciones sensibles.
Monitoreo y trazabilidad: Registrar prompts, fuentes consultadas, herramientas invocadas, respuestas, decisiones derivadas y errores. Sin observabilidad, ni seguridad ni auditoría pueden reconstruir qué pasó.
Entrenamiento a usuarios: Gran parte del riesgo entra por uso inadecuado, expectativas irreales o exceso de confianza. La concientización en LLM no debería limitarse a: “no copiar y pegar secretos”; también debe cubrir verificación, sesgos, alucinaciones, phishing asistido por IA y límites de automatización.
Cómo se ve un camino razonable de madurez
Para muchas empresas, una hoja de ruta efectiva puede verse así:
Fase 1: visibilidad
Detectar usos, inventariar casos, definir política mínima y bloquear escenarios evidentemente inseguros.
Fase 2: control
Clasificar casos de uso, revisar proveedores, introducir guardrails y exigir validación humana en procesos críticos.
Fase 3: aseguramiento
Hacer pruebas específicas sobre prompt injection, fuga de datos, abuso de herramientas, manejo de errores y escenarios adversariales. MITRE ATLAS y marcos como SAFE-AI sirven como referencia para estructurar este análisis.
Fase 4: gobernanza continua
Medir riesgo residual, revisar nuevos despliegues, ajustar controles y tratar los sistemas con LLM como parte del ciclo normal de seguridad, riesgo y compliance.
Lo importante no es “tener IA”, sino no desplegarla a ciegas
En 2026 ya no tiene sentido discutir si las empresas van a usar LLM. La pregunta útil es otra: si lo van a hacer con criterio o por inercia. Adoptar estas tecnologías sin inventario, sin clasificación de datos, sin límites de automatización y sin monitoreo equivale a abrir una capacidad nueva sin entender del todo sus efectos laterales. Y ese patrón en seguridad casi nunca termina bien.
Empezar bien no exige perfección. Exige disciplina básica, saber dónde están los modelos, qué información tocan, qué decisiones influyen y qué controles mínimos deben activarse antes de confiarles algo importante.Porque en el entorno corporativo, el problema no es que un LLM se equivoque una vez. El problema es que la empresa lo integre tan profundamente que una respuesta errónea, manipulada o indiscreta termine teniendo consecuencias reales.
