Una política de redacción para API de IA es el conjunto de reglas sobre lo que tu equipo puede enviar a un modelo, lo que puede almacenar después de que el modelo responda, lo que aparece en los registros de solicitudes y lo que puede ver el soporte cuando un cliente abre un ticket. Esto importa porque los prompts y las salidas ya no son solo entradas transitorias de desarrolladores. Se convierten en registros de depuración, evidencia de auditoría, capturas de pantalla, exportaciones, adjuntos de soporte y material de revisión de compras.
La versión débil de esta política dice "no registrar datos sensibles". Eso no basta. Los equipos necesitan decisiones a nivel de campo, responsables, ventanas de retención y manejo de excepciones antes de que el tráfico de producción llegue a una puerta de enlace de modelos. Una buena política de redacción para API de IA indica a ingeniería cuándo bloquear una solicitud, a seguridad cuándo enmascarar datos, a soporte cuándo redactar un ticket y a compras qué evidencia demuestra que el flujo de trabajo está controlado.
Flatkey es útil en esta conversación porque el sitio público actual posiciona flatkey.ai como una única clave API para el tráfico oficial de GPT, Claude, Gemini y otros modelos, con analítica de uso, controles de costo y una sola factura entre proveedores. Considéralo una superficie unificada de acceso y revisión. No lo trates como un reemplazo de tu propia clasificación de datos, revisión legal, política de retención o flujo de trabajo de redacción para soporte. Antes del despliegue, verifica la configuración exacta de la cuenta, los registros, las exportaciones, el comportamiento de retención y el alcance del DPA en tu propia cuenta de comprador.
Política de redacción para API de IA: la versión breve
Una política de redacción para API de IA debería responder cinco preguntas operativas antes de que un prompt llegue a producción:
| Pregunta | Decisión de la política | Responsable |
|---|---|---|
| ¿Qué datos están prohibidos en los prompts? | Bloquear secretos, datos de pago, credenciales en bruto, claves privadas y datos regulados no admitidos antes de la llamada a la API | Responsable de seguridad |
| ¿Qué datos se pueden enmascarar y enviar? | Reemplazar identificadores directos con tokens, hashes, etiquetas o marcadores sintéticos cuando la calidad de la tarea siga siendo suficiente | Responsable de aplicación |
| ¿Qué se almacena en los registros? | Preferir de forma predeterminada registros solo de metadatos; almacenar extractos de payload solo para casos de depuración aprobados | Responsable de plataforma |
| ¿Qué puede ver soporte? | Redactar prompts, salidas, adjuntos, capturas de pantalla y trazas del cliente antes de compartir el ticket | Responsable de soporte |
| ¿Cuándo se puede omitir la redacción? | Requerir una excepción nombrada, propósito de incidente, límite de acceso, fecha de retención y aprobación legal/de seguridad | Responsable de gobernanza |
El objetivo práctico no es eliminar cada detalle útil. El objetivo es conservar suficiente evidencia para depurar, conciliar el uso y dar soporte a los clientes sin convertir prompts, salidas, registros o tickets en registros sensibles no controlados.
Empieza con un mapa de datos, no con una lista de regex
La redacción de prompts para LLM suele fallar cuando los equipos empiezan con una lista estrecha de expresiones regulares. Las regex ayudan a encontrar patrones obvios, pero no definen la política. Empieza mapeando dónde aparece el tráfico de IA:
| Superficie del registro | Campos típicos | Tratamiento predeterminado |
|---|---|---|
| Cuerpo del prompt | Texto del usuario, argumentos de herramientas, contexto cargado, documentos recuperados, instrucciones del sistema | Clasificar antes de enviar; bloquear o tokenizar valores sensibles |
| Salida del modelo | Respuesta generada, citas, llamadas a herramientas, código, JSON estructurado | Escanear antes de mostrar, almacenar, exportar o copiar al ticket |
| Metadatos de la puerta de enlace | Proveedor, modelo, estado, latencia, recuento de tokens, ID de solicitud, espacio de trabajo, entorno | Conservar para operaciones y facturación salvo que revele contenido sensible |
| Registro de payload de la puerta de enlace | Prompt, respuesta, entrada/salida de herramientas, adjuntos, entrada de embeddings | Desactivado por defecto o bóveda de depuración con retención corta |
| Ticket de soporte | Informe del cliente, prompt copiado, salida, capturas de pantalla, archivos HAR, trazas de pila | Redactar antes de compartir ampliamente; separar la evidencia del incidente del soporte rutinario |
| Exportación de analítica | Filas de costo, filas de uso, etiquetas de cliente/equipo, categorías de error | Desidentificar etiquetas cuando las exportaciones salgan del equipo operativo |
Este mapa debería convertirse en el apéndice de tu política de redacción para API de IA. Les da a los revisores un lugar donde plantear preguntas concretas: qué campos están clasificados, cuáles están enmascarados, cuáles se conservan y qué rol puede aprobar excepciones.
Clasifica los prompts antes de la llamada al modelo
Los controles de retención del proveedor son importantes, pero no sustituyen la higiene de los prompts. Los controles de datos de la API de OpenAI indican actualmente que los datos de la API no se usan para entrenar modelos de OpenAI salvo que un cliente opte explícitamente por ello, pero también describen registros de monitoreo de abuso que pueden contener prompts, respuestas y metadatos derivados y que se conservan hasta 30 días por defecto. La documentación de retención de datos y API de Anthropic distingue de forma similar los acuerdos de tratamiento de datos, la retención cero de datos y los casos en que las entradas y salidas marcadas por seguridad pueden conservarse.
Eso significa que tu política debe evitar basarse en "el proveedor no lo usará para entrenar" como único control. Una política de redacción para API de IA en producción debería definir qué nunca cruza el límite:
| Tipo de dato | Acción recomendada | Ejemplo de sustitución |
|---|---|---|
| Claves API, tokens de sesión, tokens de actualización OAuth, claves privadas | Bloquear la solicitud y alertar al propietario | SECRET_BLOCKED |
| Números de tarjetas de pago y datos bancarios | Bloquear salvo que exista un flujo de pago aprobado y conforme | PAYMENT_FIELD_REMOVED |
| Contraseñas o respuestas de recuperación | Bloquear y crear un ticket de seguridad | CREDENTIAL_REMOVED |
| Identificadores personales directos no necesarios para la calidad de la tarea | Tokenizar o generalizar | CUSTOMER_4821, city_region |
| ID de cuenta necesarios para depuración | Hashear o usar un ID sustituto interno | acct_hash_... |
| Prompts internos del sistema y texto de política oculto | No exponer al input del usuario ni a tickets de soporte | SYSTEM_CONTEXT_REDACTED |
El clasificador de prompts no tiene que ser perfecto para ser útil. Necesita rutas de escalado. Si la solicitud contiene una credencial, bloquéala. Si contiene datos personales que el modelo no necesita, enmascáralos. Si el producto realmente necesita un valor sensible, exige una finalidad documentada, una ruta de modelo limitada, un propietario de retención y un revisor.
Para los equipos que construyen sus propios clasificadores, Google Sensitive Data Protection es un material de referencia oficial útil para los conceptos de desidentificación y transformación de redacción. Úsalo como fuente de patrones de diseño, no como prueba de que cualquier puerta de enlace tenga habilitados esos controles.
Analiza las salidas antes de que se conviertan en registros
A menudo se pasa por alto la privacidad de la salida del prompt porque los equipos piensan en la respuesta del modelo como un artefacto de visualización. En la práctica, las salidas se copian en tickets, se almacenan en historiales de chat, se incrustan en analíticas, se adjuntan a informes de errores y se pegan en correos electrónicos de clientes. Tu política de salida debe cubrir al menos cuatro riesgos:
| Riesgo de salida | Control |
|---|---|
| El modelo repite contenido sensible del prompt | Analiza el texto generado antes de la persistencia y del uso compartido con soporte |
| El modelo revela instrucciones del sistema o contexto oculto | Detecta y bloquea patrones de fuga de política o preámbulo |
| El modelo inventa datos personales o financieros | Exige revisión con conocimiento de la fuente antes de usos regulados o con impacto en clientes |
| El modelo incluye código inseguro, secretos o credenciales | Poner en cuarentena y derivar a revisión de seguridad |
La categoría de riesgo de divulgación de información sensible LLM02 de OWASP enmarca la divulgación como un riesgo del modelo y de la aplicación que puede incluir datos personales, detalles financieros, historiales médicos, datos empresariales confidenciales, credenciales y documentos legales. Es un recordatorio útil: la política de redacción para API de IA no es solo filtrado de entrada. También es inspección de salida, control de almacenamiento y control del flujo de trabajo de soporte.
Para flujos de trabajo de alto riesgo, mantén la respuesta generada separada del prompt en bruto. Almacena una transcripción redactada para operaciones rutinarias y conserva la evidencia en bruto solo en una bóveda restringida de incidentes cuando exista una finalidad aprobada.
Haz que la redacción de registros de la API de IA sea primero metadatos
La redacción de registros de la API de IA debe empezar con un valor predeterminado centrado primero en los metadatos. La mayoría de los equipos de plataforma necesitan IDs de solicitud, nombres de modelo, códigos de estado, latencia, recuentos de tokens, intentos de ruta, entorno, propietario y campos de coste. No siempre necesitan el prompt en bruto y la respuesta en bruto.
La documentación de registro de AI Gateway de Cloudflare es un buen ejemplo de por qué importa la distinción: documenta controles para recopilar registros y para recopilar cargas útiles de registros por separado, además de campos DLP cuando se activan las políticas. La documentación de observabilidad de AI Gateway de Vercel describe el registro del gasto, el uso del modelo y las métricas de observabilidad para la supervisión y la depuración. Esos ejemplos no son afirmaciones de funciones de Flatkey. Muestran el patrón operativo que todo comprador de una puerta de enlace debería evaluar: metadatos, carga útil, señales DLP, retención y eliminación son decisiones separadas.
Usa esta política de registro como base:
| Campo de registro | Predeterminado | Excepción |
|---|---|---|
| ID de solicitud, espacio de trabajo, entorno, ruta, modelo, proveedor | Conservar | Ninguna; necesario para soporte y auditoría |
| Estado, código de error, latencia, evento de reintento/respaldo | Conservar | Ninguna; necesario para la revisión de fiabilidad |
| Uso de tokens y estimación de coste | Conservar | Desidentificar etiquetas de cliente/equipo en exportaciones financieras cuando sea necesario |
| Cuerpo del prompt y de la respuesta | No almacenar de forma predeterminada | Bóveda de depuración de retención corta con incidente nombrado |
| Argumentos de herramientas y salida de herramientas | Redactar por campo; almacenar solo fragmentos aprobados | Incidente de seguridad o caso de error reproducible |
| Categoría de coincidencia DLP | Conservar IDs y categorías de la política | Evitar almacenar el secreto coincidente en sí |
La política de redacción para API de IA también debe definir la mecánica de eliminación. ¿Quién puede borrar un registro? ¿Quién puede imponer una retención legal? ¿Qué ocurre con los análisis derivados después de que se purgue una carga útil en bruto? Si el equipo no puede responder a esas preguntas, el registro de cargas útiles no está listo para un uso amplio en producción.
Redacta los tickets de soporte antes de que se propaguen
Los tickets de soporte son el lugar donde suelen filtrarse los controles de ingeniería cuidadosos. Un cliente pega un prompt completo en un ticket. Un ingeniero adjunta un trace con un cuerpo de solicitud. Una captura de pantalla incluye una clave. Una macro de soporte reenvía el hilo a otro proveedor. De repente, el registro sensible ya no está solo en la ruta del modelo; está en un help desk, una notificación por correo electrónico, una exportación de almacén de datos y una retrospectiva de incidentes.
Tu política de redacción de API de IA debe tratar el soporte como una superficie independiente:
| Artefacto de soporte | Revisión requerida |
|---|---|
| Prompt o salida del modelo copiados | Redacta identificadores, secretos y datos regulados antes de una visibilidad amplia en soporte |
| Captura de pantalla | Recorta o difumina claves, correos electrónicos, ID de cliente, cuerpos de solicitud y prompts ocultos |
| Archivo HAR o trace | Elimina encabezados de autorización, cookies, cargas útiles y URL firmadas |
| Adjunto de ticket | Redacta o elimina archivos sensibles antes de la escalada |
| Escalada a proveedor | Comparte los datos mínimos de reproducción, no el contenido bruto del cliente |
Los documentos oficiales de la API de Zendesk respaldan este modelo operativo al documentar la redacción de cadenas en comentarios de tickets, además de un endpoint separado de redacción de adjuntos de comentarios. Incluso si tu equipo usa otro help desk, el punto de la política es el mismo: la redacción en soporte debe ser un flujo de trabajo con nombre propio, no una limpieza puntual después de que alguien detecta un valor filtrado.
Define las excepciones antes de los incidentes
Toda política estricta necesita una ruta controlada de excepciones. Sin una, los equipos o bien eluden la política de forma informal o conservan muy poca evidencia para resolver problemas de producción.
Usa este registro de excepción:
| Campo | Valor requerido |
|---|---|
exception_id |
ID único vinculado al incidente o investigación |
business_purpose |
Depuración, revisión de fraude, revisión de seguridad, retención legal o soporte aprobado por el cliente |
data_scope |
Campos exactos permitidos, no "carga útil completa" por defecto |
access_group |
Personas o rol nombrados con acceso por tiempo limitado |
retention_until |
Fecha o evento que finaliza la excepción |
reviewer |
Seguridad, legal, privacidad o propietario del producto |
customer_notice_required |
Sí/no con justificación |
deletion_or_redaction_task |
Ticket de seguimiento que cierra el ciclo |
La ruta de excepciones debe ser lo bastante estricta para impedir el acceso casual a cargas útiles brutas y lo bastante rápida para la respuesta a incidentes. Para la depuración rutinaria, usa primero reproducciones sintéticas o fixtures redactados. Para retenciones legales, conserva solo el alcance requerido por el asesor legal. Para soporte al cliente, pide consentimiento antes de usar contenido bruto proporcionado por el cliente fuera del contexto original de soporte.
Pon la responsabilidad en la política
Una política sin responsables se convierte en shelfware. Asigna decisiones por superficie:
| Superficie | Propietario principal | Propietario de respaldo | Cadencia de revisión |
|---|---|---|---|
| Clasificador de prompts y reglas de bloqueo | Ingeniería de seguridad | Plataforma de aplicaciones | Mensual y después de incidentes |
| Escáner de salidas | Ingeniería de producto | Trust and safety | Mensual |
| Campos de registro del gateway | Ingeniería de plataforma | Ingeniería de seguridad | Trimestral |
| Programa de retención | Privacidad/legal | Ingeniería de seguridad | Trimestral |
| Flujo de trabajo de redacción de soporte | Operaciones de soporte | Operaciones de seguridad | Mensual |
| Desidentificación de exportaciones y analítica | Operaciones de datos/finanzas | Privacidad/legal | Trimestral |
| Aprobaciones de excepciones | Consejo de seguridad/privacidad | Comandante del incidente | En cada excepción |
Revisa la política de redacción de la API de IA después de cambios importantes del modelo, nuevas modalidades, nuevas herramientas de soporte, nuevos procesadores de datos y cualquier incidente que implique exposición de prompts o salidas. La redacción no es un proyecto puntual de regex. Es un control vivo que sigue el ciclo de vida del tráfico de IA.
Cómo deben usar esta política los compradores de Flatkey
Si tu equipo está evaluando un acceso unificado a la API de IA, usa esta política como lista de verificación de compras. Haz las mismas preguntas tanto si el tráfico pasa por cuentas directas del proveedor, un proxy interno o un gateway gestionado:
- ¿Qué campos de la solicitud son visibles en registros, exportaciones, facturas, paneles y flujos de trabajo de soporte?
- ¿Se puede desactivar, acotar o limitar en el tiempo el registro de cargas útiles?
- ¿Quién puede ver prompts y salidas en bruto?
- ¿Cómo se redactan los tickets de soporte y los adjuntos?
- ¿Qué configuraciones de retención son contractuales, configurables o solo práctica operativa?
- ¿Cómo gestiona el proveedor los subprocesadores, el alcance del DPA, las retenciones legales y las solicitudes de eliminación?
- ¿Qué evidencia puede exportar un comprador para auditoría sin exportar el contenido bruto del cliente?
Las páginas públicas actuales de Flatkey lo posicionan alrededor de un elemento clave: acceso al modelo, analítica de uso, controles de costos, saldo prepago y una sola factura entre proveedores. Eso lo convierte en un lugar relevante para centralizar la revisión operativa de la API de IA. El comprador aún necesita validar los controles específicos de la cuenta antes de tratar cualquier gateway como el sistema de registro para privacidad, retención o evidencia de soporte. Para el contexto actual de planes, modelos y recargas, revisa precios de Flatkey antes de la aprobación.
Lista de verificación de implementación
Usa esta lista de verificación antes del primer lanzamiento a producción:
- Clasifica los campos de prompt, salida, metadatos, registros, tickets, capturas de pantalla y exportación.
- Bloquea secretos y credenciales antes de la solicitud a la API de IA.
- Tokeniza o generaliza los identificadores personales que no sean necesarios para la calidad de la tarea.
- Almacena los registros de metadatos por defecto y exige aprobación para la captura de payloads sin procesar.
- Establece una ventana de retención corta para los payloads de depuración aprobados.
- Escanea las salidas antes de la persistencia, la exportación de analítica o la compartición con soporte.
- Redacta tickets de soporte, adjuntos, capturas de pantalla y trazas antes de la escalación.
- Documenta los responsables de las excepciones, las fechas de retención y las tareas de eliminación.
- Verifica los controles de datos del proveedor, los términos del DPA, el alcance de subprocesadores y la configuración de la cuenta.
- Revisa la política de redacción de la API de IA después de incidentes, nuevos modelos y nuevas herramientas de soporte.
Preguntas frecuentes
¿Qué es una política de redacción de la API de IA?
Una política de redacción de la API de IA define qué campos sensibles deben bloquearse, enmascararse, tokenizarse, conservarse, eliminarse o aprobarse en prompts, salidas del modelo, registros del gateway, exportaciones y tickets de soporte. Es más específica que una declaración de privacidad porque asigna el tratamiento y los responsables a nivel de campo.
¿Es suficiente la retención cero de datos del proveedor?
No. La retención cero de datos o una retención modificada pueden reducir el almacenamiento del lado del proveedor, pero no clasifican tus propios prompts, no limpian tus registros, no redactan tickets de soporte ni gobiernan las exportaciones. Trata la retención del proveedor como un control dentro de una política de redacción de la API de IA más amplia.
¿Deben los registros de la API de IA incluir prompts y salidas?
Los registros solo de metadatos deben ser el valor predeterminado para la mayoría del tráfico de producción. Almacena prompts y salidas sin procesar solo cuando el propósito de depuración o cumplimiento esté aprobado, el acceso esté limitado, la retención sea corta y la tarea de limpieza esté registrada.
¿Cómo debe soporte manejar los prompts de los clientes?
Soporte debe pedir la reproducción más pequeña necesaria, redactar los prompts y salidas copiados antes de compartirlos ampliamente, eliminar secretos de trazas y capturas de pantalla, y conservar la evidencia sin procesar solo en un flujo restringido de incidentes o soporte con un responsable de retención.
¿Dónde debería empezar un equipo de Flatkey?
Empieza con los enlaces internos entre el registro de payloads, la retención de datos y la gobernanza del gateway: revisa registro de payloads de la API de IA, combínalo con una lista de verificación de retención de datos de la API de IA, mapea eso a tu lista de verificación de gateway de la API de IA para GDPR, luego obtén una clave y verifica la configuración específica de la cuenta antes de producción.
Conclusión final
La política de redacción duradera para la API de IA es aquella que tus desarrolladores, el equipo de soporte, el revisor de privacidad y el responsable financiero puedan aplicar. Conserva los metadatos útiles. Enmascara o bloquea los valores sensibles antes de que se propaguen. Almacena los payloads sin procesar solo para excepciones nombradas. Redacta los tickets de soporte antes de la escalación. Luego utiliza una superficie de revisión del gateway, la documentación actual del proveedor y tu propia evidencia del DPA para demostrar que la política no solo está escrita, sino que funciona.
