Cuando una empresa evalúa implementar automatización con inteligencia artificial, hay una conversación que inevitablemente ocurre antes de que empiece cualquier proyecto. No la tiene el equipo de tecnología con el proveedor. La tiene el director de IT con el equipo legal, o el gerente general con el responsable de cumplimiento:

«¿y la seguridad de los datos?»

Es una pregunta válida. Y durante años fue también una pregunta difícil de responder con precisión, porque la oferta de herramientas de IA tenía vacíos reales en materia de control, trazabilidad y cumplimiento normativo.

Ese panorama cambió. Hoy existen arquitecturas probadas, certificaciones auditables y controles técnicos concretos que permiten automatizar procesos sensibles sin exponer la información de la empresa — siempre que el proyecto se diseñe con seguridad desde el inicio, no como capa de revisión al final.

Este artículo está escrito para los equipos de IT y legal que son los que más frecuentemente frenan — con razón — los proyectos de automatización por falta de claridad sobre qué garantías técnicas y legales existen. El objetivo es darles esa claridad.

1. Las objeciones legítimas — y por qué merecen respuesta técnica

Las objeciones de IT y legal ante proyectos de IA no son obstáculos irracionales. Son preguntas correctas ante una tecnología que, en muchos contextos, todavía no se ha explicado con el nivel de rigor que esos equipos necesitan para tomar decisiones informadas.

Estas son las seis preguntas que más frecuentemente paralizan proyectos — y que este artículo responde en detalle:

«¿Nuestros datos van a salir de la empresa para entrenar modelos de IA de terceros?»

Es la objeción más común y la más importante. La respuesta depende completamente de la arquitectura elegida. No todas las implementaciones de IA funcionan igual, y entender la diferencia es el primer paso.

«¿Quién tiene acceso a los datos que procesa el sistema?»

Una pregunta de control de acceso que tiene respuesta técnica precisa: IAM (gestión de identidades), cifrado por capa, y registros de auditoría que permiten saber exactamente qué proceso accedió a qué dato y cuándo.

«¿Cómo cumplimos con la Ley de Protección de Datos de Costa Rica y otras normativas?»

Costa Rica tiene la Ley 8968 de Protección de la Persona frente al Tratamiento de sus Datos Personales. Adicionalmente, empresas que operan con clientes europeos o de sectores regulados (salud, finanzas) deben cumplir con GDPR, PCI DSS, HIPAA u otras. Existe infraestructura certificada para cada uno de estos marcos.

«¿Qué pasa si el sistema es vulnerado?»

Una pregunta de resiliencia y respuesta ante incidentes. La respuesta incluye cifrado en reposo y en tránsito, controles de red, monitoreo continuo, planes de recuperación y seguro de responsabilidad.

«¿Podemos auditar qué hizo la IA con los datos?»

Trazabilidad total: logs de cada operación, registros inmutables de acceso, historial de decisiones del agente. Esto es técnicamente posible y, en arquitecturas bien diseñadas, es la configuración predeterminada.

«¿Qué nivel de control real tenemos sobre el sistema?»

Control de configuración, capacidad de apagar procesos, políticas de retención de datos, y definición de qué puede y qué no puede hacer el sistema. En implementaciones responsables, la empresa no pierde soberanía sobre sus datos ni sus procesos.

2. El mito del entrenamiento: ¿tus datos van a entrenar la IA de otro?

Este es el malentendido más extendido — y el que más proyectos ha paralizado innecesariamente. La idea de que «usar IA implica que mis datos van a entrenar el modelo de OpenAI, Google o Amazon» es falsa en arquitecturas de implementación empresarial correctamente configuradas.

Hay una distinción crítica que todo equipo de IT y legal debe entender:

IA como servicio público (Consumer)

Ejemplos: ChatGPT versión gratuita, Bard consumidor. En estas plataformas, los datos ingresados pueden usarse para mejorar el modelo. No hay garantías de aislamiento de datos, no existe SLA ni acuerdos de procesamiento de datos, y no son recomendables para información sensible de la empresa.

IA empresarial con datos privados (Enterprise)

Ejemplos: Amazon Bedrock, Azure OpenAI Service, Google Vertex AI Enterprise. En estas plataformas, los datos del cliente no se usan para entrenar modelos del proveedor. El aislamiento técnico y contractual está garantizado. Incluyen acuerdos de procesamiento de datos (DPA) disponibles y auditables, SLA, cifrado, controles IAM y registros de auditoría.

En términos contractuales: cuando una empresa usa Amazon Bedrock en modalidad empresarial, AWS garantiza explícitamente en sus términos de servicio que los datos del cliente no se utilizan para entrenar ni mejorar los modelos base. Lo mismo aplica para las APIs de Anthropic, Azure OpenAI y los servicios enterprise de Google. Esta garantía no existe en los productos de consumo gratuitos — de ahí la confusión.

Qué exigir contractualmente antes de implementar cualquier solución de IA

Cualquier proveedor de IA serio debe poder entregarte estos documentos antes de firmar:

• Data Processing Agreement (DPA): Contrato que establece cómo se procesan los datos, por cuánto tiempo, bajo qué jurisdicción y con qué garantías de eliminación.
• Política de no entrenamiento con datos del cliente: Confirmación explícita de que los datos no se usan para mejora de modelos. En AWS Bedrock está en los términos de servicio; en Anthropic API, en el acuerdo de uso empresarial.
• Certifications sheet: Lista de certificaciones de seguridad vigentes (ISO 27001, SOC 2 Type II, PCI DSS, HIPAA si aplica).
• Sub-processor list: Lista de terceros que pueden acceder a los datos en el contexto del servicio.

Si un proveedor no puede entregar estos documentos, eso es la respuesta.

3. Las cuatro capas de seguridad que todo proyecto de IA debe tener

Una implementación de automatización con IA segura no depende de una sola medida de protección — depende de cuatro capas que trabajan juntas. Si alguna de ellas está ausente, hay un riesgo real.

Capa 1 — Cifrado: datos protegidos en todo momento

El cifrado garantiza que los datos sean ilegibles para cualquier actor no autorizado, incluso si logra acceder a la infraestructura. Hay dos momentos en los que los datos deben estar cifrados:

• En reposo: cuando los datos están almacenados. El estándar mínimo es AES-256. En AWS, todos los servicios de almacenamiento (S3, DynamoDB, RDS, Redshift) ofrecen cifrado en reposo activable por configuración, con llaves gestionadas por el cliente (CMK) a través de AWS Key Management Service (KMS).
• En tránsito: cuando los datos se mueven entre sistemas. TLS 1.2 o superior es el estándar. En arquitecturas AWS, toda comunicación entre servicios dentro de una VPC puede configurarse para usar TLS obligatorio.

Punto crítico para IT: el cifrado con llaves gestionadas por el cliente (CMK) significa que solo la empresa tiene acceso a las llaves de descifrado. Ni AWS ni el proveedor de la herramienta de IA pueden leer los datos aunque quisieran. Este control es auditado y demostrable.

Capa 2 — Control de acceso: quién puede ver qué

El principio de menor privilegio establece que cada componente del sistema — humano o automatizado — debe tener acceso solo a los datos que necesita para su función específica, y nada más. En una implementación de automatización con IA, esto se traduce en:

• Identidades por rol (IAM): cada proceso automatizado tiene una identidad propia con permisos granulares. El agente de IA que atiende clientes puede leer el historial de pedidos, pero no puede acceder a la nómina ni a contratos internos.
• Separación de entornos: desarrollo, pruebas y producción son entornos separados con políticas de acceso independientes. Los datos reales de clientes solo existen en producción.
• Autenticación multifactor (MFA): cualquier acceso administrativo al sistema requiere verificación en dos pasos.
• Acceso temporal: los tokens de acceso expiran. Ningún proceso tiene credenciales permanentes sin fecha de vencimiento.

Capa 3 — Trazabilidad y auditoría: registro de todo

La trazabilidad responde la pregunta que más le importa al equipo legal: «¿podemos demostrar qué pasó con los datos?» Un sistema bien implementado registra automáticamente cada operación, quién la ejecutó (humano o proceso automatizado), qué datos accedió, y cuál fue el resultado. En arquitecturas AWS, esto se implementa con:

• AWS CloudTrail: registra cada llamada a la API de los servicios AWS — quién hizo qué, desde qué IP, a qué hora. Los registros son inmutables y almacenables en S3 por el período que la empresa defina.
• AWS CloudWatch Logs: monitoreo en tiempo real del comportamiento de los sistemas. Permite configurar alertas automáticas si algún proceso accede a datos fuera de su patrón normal.
• Amazon Bedrock invocation logs: registro de cada interacción del agente de IA: qué prompt recibió, qué herramientas usó, qué datos consultó, qué respuesta generó. Esencial para auditorías y para debugging.
• Registros de acceso a S3 y DynamoDB: trazabilidad de cada lectura y escritura sobre los repositorios de datos.

Para el equipo legal: estos registros son exportables, tienen timestamps verificables, y pueden presentarse en auditorías o ante la Agencia de Protección de Datos de los Habitantes (PRODHAB) en Costa Rica. No son logs internos del proveedor — son logs de la empresa, almacenados en la infraestructura de la empresa.

Capa 4 — Gobernanza de datos: quién decide qué hace la IA

Esta es la capa más frecuentemente ignorada en implementaciones apresuradas — y la más importante desde la perspectiva de cumplimiento normativo. La gobernanza de datos en el contexto de IA incluye:

• Definición de perímetro de datos: qué datos puede acceder el sistema de IA y cuáles están explícitamente fuera de su alcance. Esto se configura técnicamente (políticas IAM) y se documenta contractualmente.
• Políticas de retención: cuánto tiempo se almacenan los datos procesados por la IA, en qué formato, y cuál es el proceso de eliminación. Crítico para cumplir con el derecho de supresión de la Ley 8968 y el GDPR.
• Propósito limitado: el sistema de IA procesa datos para un propósito específico y definido. Procesarlos para un propósito diferente sin nuevo consentimiento es una violación normativa, independientemente de la tecnología utilizada.
• Responsable del tratamiento: la empresa, no el proveedor de IA, es el responsable del tratamiento de datos personales ante la ley. El proveedor es un encargado del tratamiento. Esta distinción tiene implicaciones legales directas que deben quedar claras en el contrato.

4. Seguridad en AWS: la infraestructura que IT puede auditar

Amazon Web Services es la plataforma de nube con el portafolio más amplio de certificaciones de seguridad del mercado. Para equipos de IT y legal que necesitan demostrar cumplimiento ante reguladores, clientes o consejos directivos, este nivel de documentación auditada es un activo directo.

Certificaciones vigentes de AWS relevantes para empresas en Costa Rica

AWS cuenta con las siguientes certificaciones relevantes para el mercado empresarial costarricense:

• ISO 27001: Gestión de seguridad de la información. Evalúa controles de confidencialidad, integridad y disponibilidad. Relevante para toda empresa — es el estándar base internacional.
• SOC 2 Type II: Controles de seguridad, disponibilidad, integridad de procesamiento, confidencialidad y privacidad. Auditado por terceros. Relevante para empresas que necesitan demostrar controles a clientes enterprise o inversores.
• PCI DSS Level 1: Estándar de seguridad para procesamiento de datos de tarjetas de pago. Relevante para retail, e-commerce y cualquier empresa que procese pagos con tarjeta.
• HIPAA: Privacidad y seguridad de información de salud en EE.UU. Referencia para clínicas, laboratorios, telemedicina y healthtech que operen con ese mercado.
• GDPR: Regulación de protección de datos de la Unión Europea. AWS ofrece DPA estándar compatible con GDPR. Relevante para empresas con clientes europeos o con filiales en Europa.
• FedRAMP: Estándar de seguridad para servicios de nube usados por el gobierno de EE.UU. Altamente exigente. Relevante para empresas que trabajan con gobierno o con contratistas gubernamentales.

El modelo de responsabilidad compartida: quién cuida qué

Uno de los conceptos más importantes para que el equipo de IT comprenda al trabajar con AWS — o cualquier nube — es el modelo de responsabilidad compartida. Define con precisión qué es responsabilidad del proveedor y qué es responsabilidad de la empresa.

AWS es responsable de:

• Seguridad física de los centros de datos
• Hardware, redes y virtualización
• Parches del sistema operativo de infraestructura
• Disponibilidad y resiliencia de la infraestructura
• Certificaciones de seguridad de la plataforma

Tu empresa es responsable de:

• Configuración de los servicios AWS que usa
• Gestión de identidades y accesos (IAM)
• Cifrado de datos (activarlo y administrar las llaves)
• Configuración de redes y grupos de seguridad
• Datos almacenados y cómo se usan
• Aplicaciones que construye o configura sobre AWS

Implicación práctica: AWS garantiza que la infraestructura es segura. Pero una empresa puede configurar mal los permisos IAM, dejar un bucket de S3 público accidentalmente, o implementar un agente de IA con acceso más amplio del necesario. La seguridad en la nube es segura por diseño — si se configura correctamente. Por eso el diseño de la arquitectura con criterios de seguridad desde el inicio no es opcional.

Herramientas nativas de AWS para seguridad en proyectos de IA

• AWS IAM (Identity and Access Management): Define quién puede hacer qué. Cada agente de IA, función Lambda y proceso automatizado tiene una identidad propia con permisos mínimos necesarios. Auditable en tiempo real.
• AWS KMS (Key Management Service): Gestión de llaves de cifrado. Permite que la empresa controle sus propias llaves de cifrado para todos los datos almacenados y procesados. Las llaves nunca salen del entorno de la empresa.
• AWS CloudTrail: Registro inmutable de toda actividad de API. Quién accedió a qué, cuándo, desde dónde. Fundamental para auditorías y respuesta a incidentes.
• Amazon VPC (Virtual Private Cloud): Red privada aislada para los sistemas de la empresa. Los agentes de IA y las funciones Lambda operan dentro de esta red, sin exposición directa a internet.
• AWS Security Hub: Vista centralizada del estado de seguridad de todos los servicios AWS de la empresa. Integra hallazgos de GuardDuty, Inspector, Macie y otros servicios de detección.
• Amazon Macie: Usa machine learning para descubrir y proteger datos sensibles en S3: detecta automáticamente información personal, financiera o confidencial y alerta si se accede de forma inusual.
• Amazon GuardDuty: Detección de amenazas continua. Analiza logs de CloudTrail, VPC Flow Logs y DNS para identificar comportamiento malicioso o inusual en tiempo real.
• AWS Bedrock Guardrails: Controles específicos para agentes de IA: define qué tipos de contenido puede procesar el agente, qué temas están fuera de límites, y qué respuestas están prohibidas. Auditable por diseño.

5. Cumplimiento con la Ley 8968 en Costa Rica: lo que cambia con IA

La Ley 8968 — Ley de Protección de la Persona frente al Tratamiento de sus Datos Personales — es el marco legal vigente en Costa Rica para el tratamiento de datos personales. Su ente de aplicación es la Agencia de Protección de Datos de los Habitantes (PRODHAB). Implementar automatización con IA que procese datos personales implica responsabilidades específicas bajo esta ley.

Las obligaciones que no cambian — pero que la IA hace más visibles

• Base legal para el tratamiento: el procesamiento de datos personales requiere una base legal válida: consentimiento informado, relación contractual, interés legítimo u obligación legal. Que sea un sistema de IA quien procese los datos no exime de este requisito.
• Propósito específico y limitado: los datos solo pueden usarse para el propósito declarado en la base legal. Un agente de IA entrenado con datos de clientes para atención no puede usarlos para perfilar compradores para campañas sin nueva base legal.
• Derecho de acceso, rectificación y supresión: los titulares de los datos tienen derecho a saber qué datos tiene la empresa sobre ellos, corregirlos o solicitar su eliminación. El sistema de IA debe poder ejecutar estas solicitudes — o al menos no impedirlas.
• Notificación de brechas: si hay un incidente de seguridad que compromete datos personales, la empresa debe notificar a PRODHAB. Tener logs de auditoría completos (CloudTrail, CloudWatch) facilita enormemente este proceso.
• Encargados del tratamiento: los proveedores de tecnología (AWS, el proveedor de IA) son encargados del tratamiento. La empresa es responsable. Los contratos deben reflejar esta estructura y definir las obligaciones de cada parte.

Lista de verificación legal antes de lanzar cualquier proceso de IA con datos personales

• Base legal identificada y documentada para el tratamiento de datos en el proceso automatizado.
• Política de privacidad actualizada que mencione el uso de sistemas automatizados en el tratamiento.
• Contrato con el proveedor que incluya cláusulas de encargado del tratamiento (DPA).
• Política de retención de datos definida: cuánto tiempo, en qué formato, proceso de eliminación.
• Proceso documentado para responder solicitudes de derechos ARCO (Acceso, Rectificación, Cancelación, Oposición).
• Plan de respuesta ante incidentes de seguridad que incluya el proceso de notificación a PRODHAB.
• Registro de actividades de tratamiento actualizado que incluya los procesos automatizados con IA.

6. Los riesgos reales — y cómo se mitigan

Hablar de seguridad con honestidad implica reconocer que los riesgos existen. La automatización con IA no es intrínsecamente insegura — pero hay riesgos específicos que requieren medidas específicas.

Exposición accidental de datos

Descripción: Un agente de IA con permisos mal configurados accede a más información de la necesaria y la incluye en respuestas a usuarios.

Cómo se mitiga: Principio de menor privilegio en IAM. Perímetro de datos definido en la configuración del agente. Bedrock Guardrails para limitar qué información puede incluir en respuestas.

Prompt injection

Descripción: Un usuario malicioso introduce instrucciones en su mensaje que intentan manipular al agente para revelar información confidencial o ejecutar acciones no autorizadas.

Cómo se mitiga: Bedrock Guardrails. Validación de entradas. Arquitectura que separa las instrucciones del sistema de las entradas del usuario. Monitoreo de patrones inusuales en CloudWatch.

Fuga de datos en logs

Descripción: Los registros de las interacciones del agente contienen datos sensibles almacenados en claro.

Cómo se mitiga: Configuración de enmascaramiento de datos sensibles en los logs. Amazon Macie para detección automática de datos personales en repositorios de logs. Cifrado de logs en S3.

Dependencia de tercero

Descripción: El proveedor de IA sufre una interrupción o cambia sus términos de servicio.

Cómo se mitiga: SLA documentado. Arquitectura con posibilidad de migración (evitar lock-in en capa de aplicación). Backups independientes de los datos.

Sesgo o error del modelo

Descripción: El agente toma decisiones automatizadas incorrectas con impacto en clientes.

Cómo se mitiga: Supervisión humana en decisiones de alto impacto. Umbral de confianza configurable. Registro de todas las decisiones para revisión. Proceso de corrección y retroalimentación.

Acceso no autorizado interno

Descripción: Un empleado con acceso legítimo al sistema lo usa para extraer datos fuera del propósito definido.

Cómo se mitiga: Logs de auditoría con alertas de comportamiento inusual (GuardDuty). Acceso basado en roles con revisión periódica. Separación de entornos según nivel de sensibilidad.

7. Security by design: cómo estructurar un proyecto de IA seguro desde el inicio

El error más costoso en seguridad no es ser atacado. Es diseñar el sistema sin seguridad y agregar controles al final — cuando cambiar la arquitectura es caro, lento y disruptivo. La seguridad añadida como capa de barniz nunca es tan efectiva ni tan auditable como la seguridad incorporada desde el diseño.

Estas son las decisiones de diseño que deben tomarse antes de escribir la primera línea de configuración:

• Mapa de datos sensibles: identificar qué categorías de datos va a procesar el sistema (datos personales, financieros, de salud, confidenciales de negocio) y qué nivel de protección requiere cada una.
• Perímetro del agente: definir con precisión a qué sistemas puede acceder la IA, qué operaciones puede ejecutar (solo lectura, lectura y escritura, qué tablas o registros), y qué está explícitamente fuera de su alcance.
• Política de retención y eliminación: decidir antes de implementar cuánto tiempo se retienen los datos procesados, en qué formato, y cuál es el proceso automatizado de eliminación al vencimiento.
• Supervisión humana en decisiones críticas: identificar qué tipos de decisiones del agente requieren validación humana antes de ejecutarse — aprobación de reembolsos sobre cierto monto, modificación de contratos, acceso a expedientes médicos.
• Plan de respuesta ante incidentes: documentar qué pasa si hay una brecha: quién se notifica primero (interno), en cuánto tiempo, cómo se contiene, cuándo se notifica a PRODHAB y a los afectados.
• Revisión periódica: definir con qué frecuencia se revisan los permisos del sistema, los logs de auditoría, y el comportamiento del agente. Una implementación segura en el día 1 puede volverse riesgosa en el mes 6 si los procesos cambian y el sistema no se actualiza.

8. Qué tipos de datos se pueden automatizar con IA — y cuáles requieren controles adicionales

No todos los datos tienen el mismo nivel de sensibilidad, y no todos los procesos requieren el mismo nivel de control. Esta clasificación ayuda a priorizar dónde implementar controles adicionales.

Automatizable con controles estándar:

• Datos de interacción de atención al cliente (consultas, solicitudes)
• Información de pedidos y logística (sin datos financieros completos)
• Datos de leads y pipeline de ventas (nombre, empresa, correo)
• Métricas operativas y reportes internos agregados
• Contenido de marketing y comunicaciones salientes
• Tickets de soporte técnico sin datos sensibles adjuntos

Requiere controles adicionales y revisión legal:

• Datos financieros personales (cuentas, tarjetas, historial crediticio)
• Información médica o de salud de cualquier tipo
• Datos de menores de edad
• Expedientes laborales y datos de recursos humanos
• Información clasificada como confidencial en contratos con clientes
• Datos biométricos (reconocimiento facial, huella, voz)

Conclusión: la seguridad no es el obstáculo — es el diseño

La pregunta «¿es seguro automatizar con IA?» tiene la misma naturaleza que «¿es seguro manejar un automóvil?». La respuesta depende de si el vehículo tiene los sistemas de seguridad correctos, si el conductor sigue las reglas, y si la ruta está bien planificada. No es una pregunta de sí o no — es una pregunta de cómo.

Las herramientas existen. Las certificaciones existen. Los controles técnicos existen. Lo que determina si un proyecto de IA es seguro no es la tecnología — es si fue diseñado con seguridad como requisito, no como revisión posterior.

Para los equipos de IT y legal, la conversación correcta con cualquier proveedor de automatización con IA no es «¿es seguro?» — es «muéstrame la arquitectura, los controles, las certificaciones y los contratos». Esa conversación es la que permite tomar decisiones informadas y avanzar con confianza.

¿Estás evaluando un proyecto de automatización con IA y necesitas respuestas concretas para tu equipo de IT o legal?

En SmartGo360 diseñamos implementaciones de IA con seguridad desde el primer día: arquitecturas sobre AWS con controles IAM, cifrado, trazabilidad completa y documentación para cumplimiento con la Ley 8968 y otras normativas aplicables.

Podemos acompañarte en:

• Revisión de arquitectura de seguridad para proyectos de IA en evaluación.
• Preparación de documentación técnica y legal para equipos de IT y cumplimiento.
• Implementación de controles AWS: IAM, KMS, CloudTrail, GuardDuty, Bedrock Guardrails.
• Evaluación de riesgos y plan de respuesta ante incidentes para procesos automatizados.