IA empresarial: 3 formas de uso y su riesgo real

La IA ya entró a la empresa: la pregunta es por dónde salen los datos

El 66% de los profesionales de oficina de empresas con ingresos superiores a US$500 millones admite haber usado herramientas de IA en el trabajo aun creyendo que estaban prohibidas por la política interna, y más de un tercio introdujo datos de clientes en modelos públicos. Lo midió la encuesta 2026 Shadow AI Survey de PagerDuty, realizada por Wakefield Research sobre 1.250 profesionales, y el dato resume el problema: la adopción llegó mucho antes que la gobernanza.

Para un founder, la conclusión práctica no es bloquear ChatGPT. Es entender que el riesgo no vive en el prompt que escribe tu equipo, sino en la arquitectura por la que viaja la información.

Ese es el aporte del análisis firmado por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord. En lugar de comparar modelos, distingue tres formas de consumir IA y el nivel de control real que cada una otorga sobre los datos de tu negocio.

¿Cuáles son las tres formas de usar IA en una empresa?

El punto de partida es que la IA necesita recursos de computación, almacenamiento y sistemas capaces de procesar información, y que buena parte de las empresas menos tecnológicas asocia IA con una pestaña del navegador. Bajo esa asociación, la gestión del riesgo termina apoyándose en tres elementos frágiles: políticas de uso, herramientas DLP e instrucciones dentro de los prompts.

Un prompt no es una barrera de seguridad fiable, advierte el autor: los modelos pueden recibir instrucciones adversarias (el conocido prompt injection), interpretar mal sus restricciones o generar comportamientos no previstos, algo ya explorado a fondo en la literatura sobre jailbreaks. Es la misma advertencia que repite Facundo Balmaceda, especialista en ciberseguridad de SONDA Argentina, en diálogo con Ámbito: un chatbot corporativo mal desarrollado es como dejar una puerta trasera abierta en la recepción de la empresa.

1. Navegador: el modelo más adoptado y el menos controlable

Cuando la empresa contrata licencias y los empleados acceden desde el navegador, la organización consume un servicio de un tercero bajo condiciones contractuales, configuraciones de privacidad y mecanismos de seguridad que impone el proveedor. Al pulsar enviar, los datos llegan a la infraestructura de ese proveedor.

Se pueden establecer políticas, aplicar DLP, restringir accesos y exigir garantías contractuales. Pero las funciones de protección más avanzadas suelen estar atadas a planes empresariales con costos adicionales, lo que complica su adopción en pymes y equipos chicos. Y aparece el factor humano: un empleado puede compartir información confidencial, ignorar las instrucciones internas o usar IA sin autorización. La exposición del dato ocurre antes de que cualquier instrucción dirigida al modelo tenga oportunidad de intervenir.

2. API y backend corporativo: controles antes de que el dato salga

Aquí la empresa construye su propia aplicación, con front-end y backend propios, y es el backend el que conversa con el modelo mediante una API. La diferencia es que permite aplicar medidas técnicas antes de que la información abandone el perímetro organizativo: clasificar datos, eliminar lo innecesario, aplicar pseudonimización, verificar permisos, limitar operaciones autorizadas, registrar solicitudes y revisar las respuestas del modelo antes de utilizarlas.

El proveedor sigue procesando lo que recibe, pero la organización decide mejor qué envía y para qué. El riesgo no desaparece: lo que cambia es que los controles dejan de depender de la decisión individual de cada empleado y se incorporan al flujo de información.

3. Modelo en tu propia infraestructura: control total, responsabilidad total

El tercer escenario es ejecutar el modelo dentro de la infraestructura de la organización. Hoy existen modelos con capacidades avanzadas desplegables en servidores internos: gpt-oss-20B (OpenAI), Mistral Small 3.1 de 24B, Gemma 3 de 27B (Google), Qwen3 de 32B (Alibaba), LLaMA de 65B (Meta, primera generación), Llama 3.3 de 70B y gpt-oss-120B (OpenAI), según el listado del propio análisis.

Los requisitos de CPU, GPU, memoria y almacenamiento varían según tamaño, arquitectura y nivel de cuantización. La ventaja es que front-end, backend, modelo y almacenamiento pueden quedar dentro del mismo perímetro, con control directo sobre el procesamiento, los accesos, los registros de actividad, la retención y las conexiones con otros sistemas. También permite operar sin enviar a terceros los datos usados durante la inferencia, siempre que las dependencias, la telemetría y las integraciones estén correctamente configuradas.

La contrapartida es que ahora la empresa asume proteger y mantener toda esa infraestructura. Una mala configuración, un usuario con privilegios excesivos, un conector vulnerable o un modelo expuesto generan incidentes igual de graves.

¿Qué es el Shadow AI y por qué no se resuelve con un bloqueo?

El Shadow AI es el uso de herramientas de IA para tareas de trabajo sin autorización, supervisión ni evaluación formal de la organización. Y ya no es un fenómeno marginal: según el informe 2026 Data Breach Investigations Report de Verizon, citado por TechTimes, el Shadow AI se convirtió en la tercera acción interna no maliciosa más detectada en entornos empresariales, con un aumento de cuatro veces respecto del año anterior.

El error más común es tratarlo como un problema de conducta individual. Como señala Fabián Descalzo, socio de Ciberseguridad y Gobierno Tecnológico de BDO en Argentina, en Mercado: para la tecnología quizá no ocurrió nada, pero para la organización pudo haber ocurrido mucho. Exponer información en una herramienta no evaluada puede derivar en reclamos, incumplimientos contractuales, incidentes de privacidad y pérdida de negocios, incluso sin que nadie haya instalado un software.

Bloquear tampoco resuelve: el uso se desplaza a cuentas personales o a herramientas menos visibles. En España, una encuesta de Okta y Apprize360 citada por TechTimes encontró que el 96% de los directivos confiaba en su visibilidad sobre el uso de IA mientras el 55% de los empleados declaraba usar herramientas no autorizadas. Esa brecha entre lo que cree el comité de dirección y lo que pasa en las laptops es el riesgo real.

¿Cuánto cuesta realmente una brecha vinculada a IA no gobernada?

Los números ya son lo bastante duros como para justificar una conversación de directorio:

• Las organizaciones con altos niveles de Shadow AI registraron costos de brecha US$670.000 superiores en promedio, y una de cada cinco reportó una brecha vinculada a IA no autorizada, según investigación de IBM citada por Cisco.
• El 97% de las organizaciones que sufrieron un incidente de seguridad relacionado con IA carecía de controles de acceso adecuados para IA, y el 63% de las compañías brechadas no tenía política de gobernanza de IA o la estaba redactando, según el mismo análisis.
• La investigación de brechas de 2026 citada por Cisco encontró que uno de cada cuatro ataques maliciosos fue habilitado por IA, un 56% más que el año anterior, con un costo promedio cercano a US$6 millones, alrededor de un millón por encima del promedio global.
• El 2026 Cloud and Threat Report de Netskope, citado por Cisco, muestra que la cantidad de personas que usan aplicaciones de IA generativa vía SaaS se triplicó en un año y el volumen de prompts se multiplicó por seis.

El caso más citado de fuga sigue siendo el de Samsung en 2023, cuando ingenieros de su división de semiconductores pegaron código fuente propietario y notas de reuniones internas en ChatGPT en tres incidentes separados, según el recuento de TechTimes. Y no hace falta un exploit exótico: en febrero de 2026, los investigadores de Wiz detectaron que el backend mal configurado de un servicio exponía alrededor de 1,5 millones de tokens de autenticación de agentes y 35.000 direcciones de correo, un fallo ordinario de control de acceso en una aplicación construida a toda velocidad, según relató Cisco.

¿Qué marcos y normas ya puedes usar para gobernar esto?

No hay que inventar el framework desde cero. El análisis de Cisco recomienda partir del NIST AI Risk Management Framework y adoptar ISO/IEC 42001 como sistema de gestión certificable; el especialista de BDO citado por Mercado menciona la misma norma como marco para definir responsabilidades, evaluar riesgos e impactos y establecer controles y mejora continua.

En el plano regulatorio, Cisco recuerda que la mayor parte de las reglas del AI Act europeo empezaron a aplicarse en agosto de 2026, mientras los requisitos para sistemas de alto riesgo se movieron al 2 de diciembre de 2027 y al 2 de agosto de 2028 para IA de alto riesgo embebida en productos regulados. La lección no es correr detrás de una fecha: es tener capacidad de gobernanza antes de que la exija un cliente, un formulario de seguridad o un incidente.

¿Qué significa esto para tu startup?

La buena noticia es que, con equipos pequeños, estas decisiones son más rápidas que en una corporación. Cuatro movimientos concretos:

• Clasifica el dato antes de elegir la herramienta. Como plantea Balmaceda en Ámbito, antes de preguntarse qué herramienta usar hay que tener identificado qué información es crítica, cuál es sensible y cuál es pública. No se trata de prohibir la IA, sino de fijar reglas claras.
• Haz un inventario real de uso. Pregunta abiertamente a cada equipo qué herramientas usa y para qué, y complementa con telemetría de red, identidad y DLP. Según Cisco, el descubrimiento técnico solo funciona si va acompañado de conversaciones: la demanda legítima que el Shadow AI revela es información valiosa, no una falta disciplinaria.
• Asigna la arquitectura según el dato, no según la moda. Borradores de marketing o resúmenes de documentación pública toleran navegador con plan empresarial. Contratos, datos de clientes o código fuente piden API con backend propio. Información regulada o propiedad intelectual sensible justifica evaluar un modelo local.
• Haz que la herramienta aprobada sea la más fácil de usar. Si la alternativa corporativa es más lenta o más incómoda, el equipo vuelve al atajo. La gobernanza bien diseñada funciona como facilitador, no como freno.

Y una distinción que APD recuerda y que muchos equipos mezclan: no es lo mismo una fuga de datos, que una exposición involuntaria, que la pérdida de control sobre la información. Las tres exigen respuestas distintas, y solo la primera suele activar los protocolos de seguridad.

Conclusión

Contratar licencias, integrar una API o desplegar un modelo local no determina por sí solo el nivel de seguridad de una empresa. Lo que determina el riesgo es entender el recorrido completo de la información, quién la procesa en cada tramo y hasta dónde llega tu capacidad real de control.

La IA es fácil de adoptar; gobernar su riesgo exige conocer cómo funciona y cómo la has integrado. Para una startup, la ventaja competitiva no está en usar el modelo más nuevo, sino en poder decirle a un cliente corporativo —con evidencia— dónde viven sus datos cuando los pasa por tu producto. Eso, cada vez más, es condición para cerrar contratos.

Fuentes

• Inteligencia Artificial en las empresas: Tres formas de uso. Tres niveles de control del riesgo (fuente original)
• Shadow AI Cybersecurity Risk Spikes as 45% of Workers Use Unsanctioned Tools - TechTimes
• The AI Security Paradox - How Shadow AI Became the Enterprise's Biggest Blind Spot - Cisco
• How Shadow AI Is Rapidly Outpacing Enterprise Risk Management - Forbes Technology Council
• La inteligencia artificial avanza más rápido que los controles en las empresas - Ámbito
• Shadow AI: el uso de IA sin control corporativo suma riesgos al negocio - Mercado
• Shadow AI en la empresa: riesgos de usar inteligencia artificial sin control corporativo - APD