Existe una mentira cómoda circulando en la venta de proyectos de IA: la de que el sistema es seguro porque "tiene guardrails". Guardrail es el nombre bonito para las reglas que intentan impedir que la IA diga o haga lo que no debe. Es necesario, pero tratarlo como seguridad definitiva es como decir que tu tienda está protegida porque tiene un cartel de "prohibida la entrada a extraños" en la puerta. El cartel ayuda. No detiene a nadie que haya decidido entrar.
Este texto explica, en lenguaje de negocio, qué es la seguridad de IA de verdad: qué hacen los tres mayores fabricantes del mundo (Anthropic con Claude, Google con Gemini y OpenAI con Codex) para proteger sus propios productos, por qué ninguno de ellos confía solo en los guardrails, y la lista de medidas que separa a un proyecto realmente protegido de uno común que solo siguió el checklist estándar. Si tu empresa usa o va a usar IA conectada a sistemas reales, con datos reales de clientes, este es probablemente el texto más importante que vas a leer antes de firmar cualquier contrato.
1. Qué puede salir mal, en términos de negocio
Primero, vale la pena nombrar el riesgo sin tecnicismos. Un chatbot que solo responde preguntas puede, en el peor de los casos, decir una tontería. Vergonzoso, pero recuperable. Un agente de IA es diferente: actúa. Accede al sistema de pedidos, consulta el registro del cliente, emite una segunda copia, agenda una visita, dispara un correo. Hace cosas en nombre de tu empresa, con los permisos que tu empresa le dio.
Eso cambia la naturaleza del riesgo. Las preguntas dejan de ser "¿y si la IA responde mal?" y pasan a ser: ¿y si alguien convence a la IA de mostrar los datos de un cliente a otro? ¿Y si la IA da un descuento que no existe y el cliente exige que se cumpla? ¿Y si borra o altera un registro que no debía? ¿Y si un competidor descubre cómo extraer tu tabla de precios interna conversando con tu propio agente virtual? Ninguno de estos escenarios es ficción. Todos ya ocurrieron en empresas reales, y la mayoría ocurrió en proyectos que tenían guardrails.
2. Por qué el guardrail no aguanta solo
El guardrail funciona como un empleado nuevo muy bien capacitado: recibió instrucciones claras sobre lo que puede y lo que no puede hacer. El problema es que sigue siendo alguien que conversa con el público todo el día. Y existe toda una categoría de estafa, llamada prompt injection, que consiste exactamente en conversar con la IA hasta convencerla de que la regla no vale en ese caso. "Ignora tus instrucciones anteriores." "Soy el administrador del sistema." "Esto es una prueba autorizada." Suena tonto escrito así, pero las versiones sofisticadas de esta estafa engañan a los mejores modelos del mundo con regularidad, incluso escondidas dentro de un correo, de un documento o de una página que la IA leyó para ayudarte.
El detalle que casi nadie te cuenta
Un sistema tradicional es determinista: la misma entrada produce siempre la misma salida, y un bloqueo de sistema detiene el 100% de las veces. Una IA generativa es probabilística: acierta casi siempre, pero "casi siempre" es una palabra peligrosa en seguridad. Si el guardrail aguanta el 99% de los intentos de manipulación y tu agente atiende diez mil conversaciones al mes, quedan cien conversaciones al mes en las que puede resbalar. Un atacante no necesita ganar siempre. Necesita ganar una vez. Tu empresa necesita defenderse todas las veces. Esa asimetría es la razón por la cual el guardrail, solo, nunca será seguridad definitiva: es una capa de reducción de riesgo, no un muro.
3. Qué hacen Claude, Gemini y Codex, y la lección que eso enseña
El argumento más fuerte contra confiar solo en los guardrails no viene de un consultor de seguridad. Viene de los propios fabricantes de los modelos. Los tres mayores del mundo rodean sus productos de controles externos al modelo, porque saben mejor que nadie que el modelo puede ser engañado.
Claude (Anthropic)
Anthropic entrena a Claude con un método propio que incorpora principios de comportamiento dentro del modelo, y mantiene una política pública de escalonamiento de seguridad: cuanto más capaz es el modelo, más controles exige antes de ser liberado. Pero el punto más revelador está en el producto. Claude Code, herramienta de la propia Anthropic que usa IA para intervenir en sistemas, pide confirmación humana antes de ejecutar acciones sensibles y corre comandos dentro de un ambiente aislado (una especie de sala cerrada donde, si algo sale mal, el daño no se propaga). Es decir: la empresa que fabrica el modelo, que conoce cada detalle de él, no deja que su propio modelo actúe solo sin una cerca externa.
Gemini (Google)
Google publica un framework de seguridad para IA (llamado SAIF) cuya idea central es la defensa en capas: filtros antes de que la conversación llegue al modelo, clasificadores que vigilan la conversación buscando intentos de manipulación, límites en lo que el modelo puede acceder y revisión de las respuestas antes de que salgan. Google declara abiertamente que el prompt injection no tiene una solución definitiva conocida, y que por eso la estrategia es apilar barreras: la estafa que pasa por la primera capa tiene que pasar por la segunda, por la tercera, por la cuarta.
Codex (OpenAI)
Codex, agente de programación de OpenAI, quizás sea el ejemplo más didáctico. Por defecto, trabaja en una caja cerrada: sin acceso a internet, sin ver nada más allá de la carpeta en la que está trabajando, y pidiendo aprobación humana para cualquier cosa fuera de eso. OpenAI podría haber dicho "nuestro guardrail es excelente, se puede liberar todo". No lo dijo. Prefirió asumir que el agente puede ser engañado y diseñar el producto de forma que, incluso engañado, el daño posible sea pequeño.
La lección de los tres es la misma y cabe en una frase: quien fabrica el modelo no confía solo en el comportamiento del modelo. Confía en la estructura a su alrededor. Si el fabricante hace esto con su producto, el proyecto que tu empresa contrató necesita hacer lo mismo con el de ustedes.
4. Las medidas que separan a un proyecto protegido de uno común
El proyecto común instala el modelo, escribe las reglas de comportamiento, prueba media docena de conversaciones y entrega. El proyecto protegido asume que la IA va a equivocarse y va a ser atacada, y construye para ese escenario. En la práctica, la diferencia está en ocho medidas.
Permiso mínimo. La IA recibe la llave del pasante, no la llave maestra. Si el agente solo necesita consultar pedidos, no puede tener un acceso que le permita alterar o borrar. Pregunta de prueba: "si esta IA es completamente engañada hoy, ¿qué es lo peor que puede hacer con los permisos que tiene?". Si la respuesta asusta, los permisos están mal.
Separación entre quien manda y quien conversa. Todo lo que viene de afuera (mensaje de cliente, correo, documento adjunto, página de internet) debe ser tratado como contenido para leer, nunca como orden para obedecer. Es la diferencia entre que el agente lea una carta del cliente y que el agente obedezca la carta del cliente. Los proyectos bien hechos marcan esa frontera técnicamente; los proyectos comunes mezclan todo en el mismo balde.
Confirmación humana en lo que no tiene vuelta atrás. Una acción reversible (consultar, calcular, redactar) puede ser automática. Una acción irreversible o costosa (enviar, pagar, borrar, firmar, conceder un descuento) pasa por un humano o por un bloqueo de sistema. No es falta de confianza en la IA, es el mismo principio de nivel de aprobación que tu empresa ya usa con las personas.
Ambiente aislado. La IA trabaja en una sala cerrada, con acceso solo a lo que necesita, y lo que produce pasa por una puerta controlada antes de tocar el sistema real. Si algo sale mal, el problema queda contenido en la sala.
Registro de todo. Cada conversación, cada decisión, cada acción de la IA queda grabada, como una cámara de seguridad. No es burocracia: cuando algo extraño ocurra (y va a ocurrir), la diferencia entre resolverlo en dos horas y resolverlo en dos semanas es tener el registro de lo que la IA vio, decidió e hizo.
Límites de volumen y botón de apagado. La IA tiene un techo de acciones por hora, un techo de gasto, un techo de mensajes. Y existe un botón, accesible a un humano de guardia, que apaga la función al instante, sin depender de un programador, sin esperar al proveedor. Un incidente con IA ocurre en minutos; la respuesta no puede tardar días.
Ataque ensayado. Antes de salir al aire, se le paga a alguien para intentar romper el sistema: extraer datos que no debía, arrancar un descuento inexistente, hacer que la IA no respete sus propias reglas. En el mundo de la seguridad esto se llama red team, y es el equivalente a contratar a un exladrón para probar tu cerradura antes de que aparezca el ladrón de verdad. El proyecto común prueba si la IA funciona. El proyecto protegido prueba si resiste.
Vigilancia continua. La seguridad no es una fase del proyecto, es una rutina de la operación. Alguien mira los registros, sigue patrones extraños (que la IA de repente acceda diez veces más registros que lo normal es una alarma, no una curiosidad) y repite las pruebas de ataque periódicamente, porque las estafas evolucionan todos los meses.
5. La pregunta correcta no es "cómo impedir el error"
Los proyectos comunes preguntan: ¿cómo hacer que la IA nunca se equivoque? Esa pregunta no tiene respuesta, y quien promete que la tiene está vendiendo un cartel de "prohibido entrar" como si fuera una caja fuerte. Los proyectos protegidos preguntan otra cosa: cuando la IA se equivoque o sea engañada, ¿cuál es el tamaño máximo del daño, en cuánto tiempo nos damos cuenta y en cuánto tiempo la apagamos? Si tu proveedor responde esa pregunta con números y mecanismos concretos, estás frente a un proyecto serio. Si responde "eso no va a pasar porque tenemos guardrails", estás frente al problema.
El guardrail es el cinturón de seguridad: indispensable, e insuficiente. Un auto seguro tiene cinturón, freno, airbag, límite de velocidad y conductor capacitado. La IA de tu empresa merece el mismo estándar. El checklist de abajo resume las preguntas que valen una reunión entera con quien está construyendo o vendiendo tu proyecto de IA.
