Seguridad en IA generativa de vídeo: qué aprende phoneIA de Sora 2

Qué ha publicado OpenAI sobre Sora 2 y la seguridad en modelos generativos

El 23 de marzo de 2026, OpenAI publicó el documento "Creating with Sora Safely", en el que detalla las protecciones concretas que han integrado tanto en Sora 2 como en la plataforma social que lo acompaña. El punto de partida es claro: un modelo de vídeo de última generación plantea retos de seguridad distintos a los de un modelo de texto o imagen, y la respuesta no puede ser solo un filtro de salida, sino una arquitectura diseñada desde los cimientos.

El documento no es un comunicado de relaciones públicas: enumera categorías de riesgo específicas, describe los mecanismos de mitigación y reconoce que algunas amenazas son novedosas. Eso lo convierte en una referencia útil para cualquier equipo que trabaje con IA generativa, aunque su producto no genere vídeo.

Qué cambia técnicamente: los tres ejes del enfoque de OpenAI

Del documento se extraen tres patrones de diseño que OpenAI aplica de forma transversal:

• Protecciones en capa de modelo, no solo en post-procesado. Las restricciones se entrenan dentro del modelo, no se añaden como un wrapper externo. Esto reduce la superficie de evasión porque no existe una capa de filtro independiente que se pueda sortear con prompts adversariales.
• Clasificación de riesgo por tipo de contenido y contexto de uso. No todos los outputs tienen el mismo perfil de riesgo. Sora 2 distingue entre plataforma pública, uso de API y uso interno, aplicando umbrales distintos según el canal. Es una arquitectura de confianza diferenciada, no un único interruptor de on/off.
• Trazabilidad y atribución. Los vídeos generados llevan metadatos de procedencia (C2PA) para que cualquier sistema downstream pueda verificar el origen. La seguridad no termina en la generación: se extiende a la cadena de distribución.

Estos tres ejes no son exclusivos del vídeo. Son principios de ingeniería aplicables a cualquier sistema que genere contenido o tome decisiones autónomas en nombre de un usuario o una empresa.

Por qué esto es relevante para un agente de voz IA como phoneIA

phoneIA utiliza el módulo Voz Entrantes para atender llamadas 24/7 con un agente Retell AI que habla más de 30 idiomas, califica leads y crea fichas en el CRM. Es, en esencia, un sistema generativo de voz que actúa en nombre de una empresa ante clientes reales. Los riesgos no son los mismos que en Sora 2, pero la lógica de diseño es análoga.

Cuando un agente de voz responde una llamada, genera lenguaje en tiempo real, toma micro-decisiones sobre qué información compartir y representa la marca del cliente. Si el agente alucina un precio, confirma una cita que no existe o da información incorrecta sobre un servicio, el daño es inmediato y concreto: un cliente molesto, una venta perdida o, en casos más sensibles como clínicas, un error con consecuencias reales.

El enfoque de OpenAI refuerza algo que en phoneIA ya aplicamos, pero que vale la pena articular con precisión:

• Las restricciones deben estar en el prompt del sistema, no solo en la lógica de la aplicación. El agente de Voz Entrantes tiene un system prompt estructurado que define qué puede decir, qué debe escalar a un humano y qué información nunca debe revelar. No es un filtro externo: es parte de la instrucción base del modelo.
• El contexto de uso determina el umbral de riesgo. Un agente que atiende consultas de una clínica dental tiene restricciones más estrictas sobre diagnósticos que uno que gestiona reservas de una peluquería. phoneIA permite configurar el comportamiento del agente por tipo de negocio.
• La trazabilidad es auditable. Cada llamada genera una transcripción en tiempo real que queda vinculada al contacto en el CRM. Si el agente dice algo incorrecto, hay un registro completo para revisarlo y corregir el prompt.

Ejemplo de uso para una PYME: clínica de fisioterapia

Una clínica de fisioterapia en Madrid recibe entre 40 y 60 llamadas diarias. Fuera del horario de apertura, esas llamadas se pierden o van al buzón de voz, que nadie escucha. Con el módulo Voz Entrantes activo, el agente atiende las llamadas a las 22:00 con el mismo guion que a las 10:00.

Aplicando los principios de seguridad descritos arriba, la configuración correcta para este caso incluye:

• El agente nunca da consejos clínicos. Si el paciente describe síntomas, el agente registra la información y confirma que un fisioterapeuta le llamará en horario de apertura. Esta restricción está en el system prompt, no en un filtro posterior.
• El agente solo gestiona citas y datos de contacto. No tiene acceso a historial clínico ni puede modificar tratamientos. El scope está acotado por diseño.
• Cada llamada genera una transcripción auditada que el responsable de la clínica puede revisar semanalmente para detectar patrones o errores en el comportamiento del agente.

El resultado es un sistema que escala la capacidad de atención sin escalar el riesgo operativo, que es exactamente lo que OpenAI describe como objetivo en su documento sobre Sora 2.

Conclusión: la seguridad en IA generativa no es un add-on, es arquitectura

El documento de OpenAI sobre Sora 2 es útil no solo para quienes trabajan con vídeo generativo. Es una demostración de que los sistemas de IA que operan en entornos reales, con usuarios reales y consecuencias reales, necesitan un diseño de seguridad integrado desde el principio. No basta con añadir un filtro al final del pipeline.

Para una PYME que evalúa incorporar un agente de voz IA, la pregunta correcta no es «¿funciona bien?», sino «¿cómo está limitado cuando no sabe algo?» y «¿hay trazabilidad de lo que dice?». Esas dos preguntas son las que separan un sistema fiable de uno que crea problemas. Si quieres ver cómo phoneIA responde a ambas en la práctica, ver el módulo Voz Entrantes.