Seguridad de contenido en IA: inyección de prompts, enmascaramiento de PII y auditoría

Las empresas pueden implantar la seguridad de contenido en IA aplicando controles de políticas en ambos lados del flujo del servicio de modelos. El diseño de referencia inspecciona el contenido entrante antes de llegar al modelo y el saliente tras su generación, aplicando después acciones como bloquear o reescribir, enmascarar datos confidenciales, gestionar etiquetas de contenido, conservar registros de inspección y vincular el servicio con registros de auditoría operativa de solo anexado.

El principio de funcionamiento es que la seguridad de contenido y la auditoría deben formar parte integral de la entrega del servicio. Si los controles residen únicamente en una herramienta externa de cumplimiento añadida tras el despliegue, gobernar el servicio del modelo de forma coherente resulta muy complicado.

¿Dónde debe realizarse la inspección de contenido?

El diseño de referencia adopta una inspección dual, tanto en la entrada como en la salida. La inspección entrante tiene lugar antes de que la petición llegue al modelo. La inspección saliente se realiza después de que el modelo genere la respuesta y antes de que el contenido se entregue externamente. Juntas configuran una cadena de inspección de cinco pasos dentro del diseño del producto, aunque el material de origen no desglosa los cinco pasos por su nombre, de modo que no deben inventarse aquí.

Lo que el material respalda con claridad es el control bidireccional. La inspección entrante aplica políticas a la petición del usuario y la inspección saliente aplica políticas al resultado generado. La distinción es determinante porque los riesgos difieren en cada extremo. Un patrón de inyección de prompts es un riesgo en la entrada, mientras que la generación de contenido sensible o información sin enmascarar es un problema en la salida. Ambos lados exigen cobertura.

¿Qué grupos de políticas de contenido se incluyen?

La documentación detallada de seguridad de contenido recoge seis grupos de políticas: contenido político o sensible, contenido sexual o violento, inyección de prompts, enmascaramiento de PII, diccionarios personalizados y etiquetado de contenido.

Estas categorías proceden del diseño del producto original. Deben tratarse como grupos de políticas configurables, ya que no pretenden ser una definición universal de todos los riesgos existentes en seguridad de contenido. La empresa puede emplearlas para definir qué debe detectarse y qué acción debe seguir. La fuente contempla además la revisión manual para ciertos registros de inspección, ofreciendo un cauce en el flujo de trabajo para aquellos casos que no deben resolverse de forma automática.

¿Cómo debe encajar la protección contra inyección de prompts en el servicio?

La protección contra inyección de prompts debe formar parte de la inspección de contenido entrante, antes de que la solicitud alcance el modelo. El diseño incluye la inyección de prompts como uno de los seis grupos de políticas de detección, y la cadena de inspección puede identificar una coincidencia y luego bloquear o reescribir según la política establecida.

El material no describe un algoritmo específico para detectar inyecciones de prompts, por lo que la orientación que respalda es arquitectónica: inspeccionar antes del modelo, aplicar una política concreta, registrar el evento, conservar el resultado de la inspección y escalar o revisar cuando sea necesario. Así se mantiene el control sobre la inyección de prompts dentro de la ruta de entrega del servicio, en lugar de confiar únicamente en la formación del usuario o en el código de la aplicación.

¿Qué función cumple el enmascaramiento de PII en este diseño?

El enmascaramiento de PII forma parte de los grupos de políticas de seguridad de contenido, y la interfaz detalla también que el contenido original se enmascara de forma automática en los registros de inspección. Esto proporciona dos controles complementarios. Mediante el enmascaramiento a nivel de política, la información personal sensible se detecta y enmascara como parte de la inspección de contenido. Mediante el enmascaramiento a nivel de registro, el contenido original inspeccionado se enmascara en la interfaz o en el registro archivado, impidiendo que la revisión operativa exponga datos sensibles innecesarios.

El material de referencia no define qué campos de PII se detectan ni el formato exacto del enmascaramiento. Esos aspectos deben configurarse de acuerdo con los requisitos de datos de cada empresa en lugar de deducirse arbitrariamente.

¿Por qué la inspección de entrada y salida debe usar el mismo marco de políticas?

Emplear el mismo marco en ambos extremos mantiene la coherencia entre lo que se permite como entrada y lo que se autoriza como salida. Una política sobre lenguaje violento o información médica no debería cambiar de criterio según el sentido del tráfico. Compartir el marco facilita además la configuración y unifica los informes de cumplimiento.

La separación de responsabilidades sigue siendo clara: la entrada filtra peticiones maliciosas o no conformes y la salida comprueba que el modelo no genere datos sensibles, alucinaciones problemáticas o textos prohibidos. El marco común unifica las reglas, la severidad y el registro.

¿Para qué se utilizan los diccionarios personalizados?

Los diccionarios personalizados constituyen uno de los seis grupos de políticas en el diseño original. Permiten a la organización añadir términos propios o patrones lingüísticos específicos que las categorías estándar no cubren adecuadamente. El material no fija el formato del diccionario ni el método de concordancia.

En el plano operativo, permiten ampliar la política de seguridad con vocabulario específico de la organización, dando soporte a requisitos de revisión internos sin tener que modificar el modelo. Los diccionarios personalizados deben versionarse y gobernarse igual que el resto de las políticas para que los cambios sigan siendo auditables.

¿Qué es el etiquetado de contenido en el diseño de partida?

El etiquetado de contenido es a la vez un grupo de políticas de detección y una obligación de cumplimiento normativo en el material original. La sección de gobernanza indica que el contenido generado debe etiquetarse según corresponda, y la sección de seguridad de contenido sitúa el etiquetado entre cuatro requisitos obligatorios de cumplimiento. No se especifica el formato exacto de la etiqueta.

La conclusión fundamentada es que el etiquetado se concibe como parte del flujo de gobernanza del servicio de modelos, y un equipo no debería tratarlo como un simple detalle visual optativo. El servicio debe reconocer cuándo aplica el etiquetado y conservar pruebas de que el requisito se cumplió.

¿Qué debe ocurrir ante una coincidencia con una política?

El diseño admite el bloqueo o la reescritura según la política, de modo que la respuesta varía en función de la configuración y no impone una acción fija única. Entre las salidas que respalda la fuente figuran el bloqueo, la reescritura, el enmascaramiento, el etiquetado y la revisión manual.

No todas las políticas requieren la misma respuesta. Una coincidencia por inyección de prompts puede bloquearse, una alerta por PII puede resolverse mediante enmascaramiento y una regla de etiquetado puede autorizar la entrega añadiendo la etiqueta preceptiva. Lo fundamental es que la acción esté predefinida y quede registrada. El servicio no debe alterar contenido sin dejar constancia en la inspección.

¿Cómo debe encajar la revisión manual en el proceso?

La revisión manual debe gestionar aquellos casos que la política derive al criterio humano. El ejemplo de origen muestra 12 registros de inspección, de los cuales 3 están pendientes de revisión manual. Esas cifras describen la interfaz de muestra y no representan una proporción operativa general.

La capacidad relevante es el estado de revisión. La plataforma debe ser capaz de distinguir entre registros aprobados automáticamente, bloqueados o reescritos de forma automática, pendientes de revisión manual o revisados y resueltos. Esto vuelve auditable el flujo de seguridad de contenido y ofrece una vía controlada para situaciones que no deben resolverse únicamente mediante automatización.

¿Qué debe contener un registro de inspección?

El diseño señala que los registros de inspección se conservan y que el contenido original se enmascara automáticamente. Un registro útil basado en este esquema vincula la hora de inspección, la categoría de la política, la etapa de entrada o salida, la medida adoptada, el contenido o evidencia enmascarada, el estado de revisión y el contexto del servicio de modelos.

La pasarela general del servicio incorpora también auditoría de invocaciones, y vincular el registro de inspección con la llamada al servicio facilita notablemente las investigaciones posteriores. Como la fuente no detalla un esquema de campos completo, cada implementación debe definir los campos precisos preservando siempre esa trazabilidad.

¿Cómo se relacionan los registros de invocación con la seguridad de contenido?

La cadena del servicio de modelos incluye la auditoría de invocaciones en la pasarela, mientras que la cadena de seguridad de contenido genera registros de inspección. Ambas responden a preguntas distintas. La auditoría de invocación indica quién o qué llamó al servicio y qué ocurrió en la frontera del mismo. La inspección de contenido indica qué política de seguridad se activó y qué medida se adoptó.

El diseño más sólido enlaza ambas facetas mediante un identificador compartido de petición o invocación. La documentación sitúa claramente ambas capacidades dentro de la cadena global de servicio y gobernanza, aunque no especifique la clave de unión concreta. Operativamente, los registros deben poder rastrearse desde la llamada al servicio hasta el resultado de la inspección.

¿Cómo deben relacionarse las claves de API y las etiquetas de proyecto con la auditoría?

El diseño del servicio contempla la gestión de claves de API y exige vincular cada clave a una etiqueta de proyecto para una correcta imputación del uso. Esto también influye en la auditoría, ya que una llamada debe contar con un contexto claro de inquilino o proyecto. Ese contexto permite saber qué proyecto invocó el modelo, qué clave se utilizó, qué servicio atendió la solicitud, cuántos tokens se consumieron y si se disparó alguna política de contenido. Sin atribución de proyecto, tanto la facturación como la investigación resultan mucho más difíciles.

En cuanto a la cadena de servicio, qué es MaaS y cómo funcionan juntos los repositorios de modelos, instancias de inferencia, API gateways y medición de tokens explica dónde se ubican la gestión de claves y la auditoría de invocaciones.

¿Qué deben registrar los logs de auditoría operativa?

El modelo de gobernanza exige que las operaciones sean rastreables por persona, momento, objeto afectado y acción. Registra además la IP de origen, la cuenta, el éxito o fallo, una comparativa campo a campo antes y después del cambio, soporte para instantáneas JSON completas y una clasificación de riesgos.

Se trata de registros de cambios operativos, distintos de las inspecciones de contenido, y ambos resultan necesarios. La auditoría de contenido explica cómo procesó el servicio una petición. La auditoría operativa explica quién modificó la configuración del servicio, la política de seguridad, los permisos u otro objeto gobernado. Conviene mantenerlos separados, ya que un evento de inspección y un cambio administrativo constituyen eventos de auditoría de naturaleza distinta.

¿Por qué los registros de auditoría deben ser de solo anexado?

El diseño de gobernanza aplica un modelo de auditoría de solo anexado (append-only). La cuenta de la aplicación puede consultar e insertar registros de auditoría, pero no modificarlos ni eliminarlos, lo que protege el historial frente a alteraciones ordinarias a nivel de aplicación.

Si un administrador actualiza una política de seguridad de contenido, la constancia de esa acción debe permanecer inalterada. Si se revisa un registro de inspección, la revisión debe sumar trazabilidad en lugar de reescribir el evento histórico sin avisar. El origen especifica además una retención particionada mensual para la auditoría operativa. El diseño exacto del almacenamiento puede variar, siempre que la aplicación que generó la evidencia de auditoría no pueda editarla libremente.

¿Cuánto tiempo deben conservarse los registros de seguridad de contenido?

La página detallada de seguridad de contenido fija una retención de 180 días como requisito en el diseño de partida. La sección general de gobernanza señala asimismo que los registros deben conservarse según los requisitos de cumplimiento, y ambas pautas deben interpretarse de manera conjunta.

El ejemplo utiliza 180 días, mientras que la retención efectiva debe responder a las obligaciones normativas y corporativas que apliquen a cada despliegue. El material no sostiene que los 180 días constituyan una obligación legal universal en cualquier lugar.

¿Qué requisitos de cumplimiento normativo se contemplan en el origen?

La documentación enumera cuatro requisitos de cumplimiento para servicios de modelos a gran escala: registro del servicio de modelos grandes, registro del algoritmo, etiquetado de contenido y retención de registros. Los califica como exigencias obligatorias dentro de su contexto operativo de referencia.

Este artículo conserva ese enfoque sin extrapolarlo como norma general para todas las jurisdicciones. Las empresas que operen en otros marcos deben adaptar sus propios imperativos regulatorios a esta misma arquitectura de gobernanza, que conserva toda su utilidad incluso cuando los compromisos normativos varían.

¿Cómo debe proteger el control de acceso la gestión de seguridad de contenido?

La capa de gobernanza de referencia se apoya en un árbol organizativo de tres niveles, una matriz de permisos por roles y menús, el principio de mínimo privilegio, autorización diferenciada para operaciones sensibles y aprobación previa para cambios. Las políticas de seguridad de contenido y los datos de auditoría deben quedar bajo esos mismos controles.

Un usuario con permisos para consultar el uso de modelos no necesita obligatoriamente acceso para modificar reglas de inyección de prompts. Un desarrollador autorizado para publicar una aplicación no tiene por qué poder alterar o eliminar políticas de seguridad. El principio de mínimo privilegio pertenece a la misma capa de gobernanza que la inspección de contenido.

¿Cómo deben auditarse los cambios en las políticas?

Los cambios en las políticas deben someterse a los mismos controles de gestión de cambios que cualquier otra operación sensible. El diseño de auditoría registra los valores previos y posteriores, de modo que un cambio en una política de seguridad conserva la configuración antigua, la nueva, el responsable, la fecha, la aprobación y el resultado.

Cualquier ajuste en las reglas de inyección de prompts o de PII puede alterar el comportamiento del servicio de inmediato. Si una modificación provoca bloqueos inesperados o pasa por alto una detección, el equipo necesita averiguar qué cambió y cuándo.

Para una perspectiva global del proceso de control, cómo los equipos de TI pueden crear un proceso de gestión de cambios auditable para operaciones de infraestructura expone la articulación conjunta de valores previos y posteriores, aprobaciones y validaciones.

¿Qué debería mostrar un panel de operaciones de seguridad de contenido?

Un panel basado en el diseño de partida puede mostrar el estado de la inspección entrante y saliente, la categoría de la política, los registros activados, los casos bloqueados o reescritos, los registros enmascarados, la cola de revisión manual, el estado del etiquetado, el estado de retención de registros, el servicio de modelos asociado y un enlace a la auditoría de invocaciones.

La interfaz de origen integra la cadena de inspección, seis categorías de políticas, cuatro requisitos normativos y los registros de revisión, proporcionando a los operadores un punto único donde supervisar la actividad de las políticas y el estado de la gobernanza.

Un ejemplo práctico de plataforma que incluye inspección entrante y saliente, políticas de inyección de prompts, enmascaramiento de PII, etiquetado de contenido y funciones de auditoría de solo anexado es Sensaka.

Al implantar estos controles, conviene tener presente un principio esencial: cada petición al servicio de modelos debe pasar por los controles de seguridad exigidos, cada acción sobre las políticas debe dejar un registro rastreable y cada modificación administrativa de esas reglas debe ser igualmente auditable. De este modo, tanto las incidencias de contenido como las variaciones de configuración podrán analizarse con posterioridad.