Quédate primero con esto: lo que hay que comprobar antes de pegar en una IA es si esta cadena de salida todavía contiene campos sensibles en claro. Apagar el interruptor de entrenamiento, o pasar a un chat temporal, solo cambia cómo la otra parte retiene y aprende. No cambia el hecho de que los campos ya han salido. Los pasos de abajo son una comparación que puedes repetir, no un adjetivo nuevo.
Responde a la intención de búsqueda en una frase
Ocultar un ticket o un registro antes de pegarlo en una IA significa: antes de que el texto salga de la pestaña que estás viendo, enmascara con reglas teléfonos, documentos, correos, API Key habituales e IP, y luego revisa a mano las contraseñas y cadenas de conexión sin formato fijo. El objeto de la comprobación es la copia que vas a pegar, no un sello de «procesado» en la página.
Esta nota es para desarrolladores, operaciones y quien en soporte suelta material en una caja de IA. No sustituye las instrucciones de la limpieza de privacidad ni repite el recorrido general de Network sobre «si el cifrado local subió algo». Lo que te llevas es qué campos suelen esconderse en un registro, qué cubren las reglas y cuándo un secreto que queda debe pasar a un marcador o a un Burn-Link.
Pegar en una IA no es el mismo límite de salida que enviárselo a un compañero
Cuando le envías un ticket a un compañero, el destinatario suele ser alguien conocido y el material acaba en un sistema de incidencias o en un historial de chat. Cuando lo pegas en una IA de consumo, esos mismos caracteres también entran en los servidores de ese producto, en su historial de conversación y en las condiciones de tratamiento vigentes ese día. El FAQ de Data Controls de OpenAI lo deja escrito: una cuenta personal puede desactivar «Improve the model for everyone»; los chats siguen apareciendo en el historial, solo que ya no se usan para entrenar el modelo. Temporary Chat se salta historial y entrenamiento, pero puede conservarse hasta unos 30 días para vigilar abusos.
Las condiciones cambian y cada producto es distinto. El juicio que puedes terminar ahora mismo es más estrecho: en cuanto pegas y envías, esos caracteres han salido de este equipo. El interruptor de entrenamiento responde a «¿lo usarán para mejorar el modelo?». No responde a «¿lo han recibido?».
Así que pregunta primero «¿debe este bloque salir de este equipo?» y después «¿cómo lo retendrá la otra parte?». La segunda pregunta pertenece al centro de ayuda de ese producto. La primera la puedes cerrar con una tabla de comparación antes de pulsar enviar.
No experimentes con un DNI real, una API Key que aún no has rotado o la contraseña de una base de producción. Prepara un ticket falso y desechable. Escribe el teléfono y la clave como canarios que existan solo en esta pasada. Estás comprobando máscaras y el límite de salida, no volviendo a exponer un secreto.
Campos que más a menudo se cuelan en tickets y registros
Lo que se filtra rara vez es un contrato entero. Es un campo corto en medio de una frase: un correo en una traza, un teléfono en el pie de una captura, una cabecera copiada Authorization: Bearer …, una IPv4 de una página de inicio de sesión interna. Cualquiera de esos basta para convertir el siguiente chat en una copia en claro.
Ordenar por dónde aparece el campo sirve más que ordenar por lo «sensible» que se siente.
| Dónde aparece | Campos típicos | Qué hacer antes de enviar |
|---|---|---|
| Tickets de soporte, transcripciones de chat | Teléfonos de España y LatAm, internacionales, correos, últimos dígitos de un documento | Enmascara con reglas y luego revisa a mano el redactado informal |
| Registros de aplicación, trazas de error | Correos, IPv4 / IPv6, algún token suelto | Enmascara IP y correos; mira si el token tiene un prefijo fijo |
| Trozos de configuración, ejemplos de curl | sk-, AKIA, ghp_, Bearer |
Las reglas aciertan prefijos habituales; lo que no acierten pasa a un marcador |
| Notas de relevo, pasos de recuperación | Contraseñas de base de datos, códigos de recuperación, cadenas de conexión enteras | No lo pegues en la IA; usa Burn-Link o deja solo un marcador |
| Enlaces compartidos | utm_*, fbclid, gclid |
Quita el seguimiento primero y luego decide si esa URL entra en el prompt |
Los campos que «no parecen un secreto» también merecen una mirada. Una IP interna marca un segmento. Los cuatro últimos dígitos de un DNI, apilados con un nombre que ya está en el ticket, pueden identificar a una persona. Por defecto las reglas dejan un poco del inicio y del final para que confirmes «esta es la misma fila que acabo de pegar». Ese resto es para tu comprobación, no una prueba de anonimización.
Qué cubre el enmascarado por reglas, y qué no
El enmascarado por reglas en el navegador es coincidencia de patrones: expresiones regulares encuentran tramos que parecen teléfonos, documentos, correos, prefijos de clave e IP, y los sustituyen por una máscara. No entiende el sentido y no lee tu sistema de tickets.
Toma Ocultar datos en la limpieza de privacidad de FastPwd como ejemplo. La pestaña actual puede detectar teléfonos internacionales; documentos (DNI, NIE, CURP y SSN); tarjetas de 13–19 dígitos que pasan Luhn; correos; prefijos habituales de API Key / Token (por ejemplo sk-, sk-proj-, AKIA, ghp_, github_pat_, glpat-, Bearer); además de IPv4 e IPv6 habituales. Por defecto se conservan un poco el inicio y el final para que compruebes el acierto; también puedes poner asteriscos en todo el valor. Un texto de más de 512 KB hay que trocearlo. La página está lista para usar: no hace falta cuenta.
Lo que se le escapa es igual de concreto. Una contraseña sin prefijo, una clave partida con espacios, texto que solo existe en una captura, o el truco de escribir 1 como l, se cuelan. Direcciones postales, números de empleado y nombres internos de proyecto no están en esta lista. Un resultado a cero aciertos significa «estos patrones no coincidieron». No significa «este bloque se puede enviar a cualquiera».
Ahí también se separa este artículo de la página de la herramienta. La herramienta responde cómo enmascarar ahora. Esta nota responde si, después de la máscara, aún debes pulsar enviar. El panel de resultado muestra una comparación de caracteres y los tipos acertados, y no publica el texto original en una API; aun así, mira la celda que vas a pegar antes de enviarla.
Haz una comparación con canario antes de enviar
Prepara un ticket falso y desechable. Escribe un teléfono que exista solo en esta pasada, un correo como canary-fp-20260901@example.com, una clave falsa con un prefijo habitual como sk-proj-canaryfp20260901xxxx, y una contraseña falsa sin prefijo como canary-plain-pass-20260901. El canario sirve para buscar. No es una demo de que «la herramienta es lista».
- Pega el ticket falso en el recuadro de Ocultar datos y ejecuta el enmascarado. Compara el resultado: las claves con prefijo, los correos y los teléfonos deberían llevar asteriscos; la contraseña sin prefijo suele seguir ahí.
- Sustituye cualquier contraseña en claro que quede por un marcador como
[DB_PASSWORD]. No esperes que una regla detecte un redactado informal del tipo «la contraseña es xxx». - Copia solo el texto del resultado. Antes de pegarlo en la caja de la IA, busca el canario con el buscador del sistema: el texto en claro completo del correo falso y de la clave falsa no debería aparecer.
- Si también quieres confirmar que la propia página de ocultar datos no envió el original, abre Network en las herramientas para desarrolladores, marca Preserve log y busca el mismo canario en líneas de petición, cuerpos e informes de analytics.
Lee el panel de resultado, no el texto del botón
«Ocultados 4 tramos» solo significa que las reglas acertaron cuatro trozos. No te dice que una quinta contraseña sigue ahí. La comparación pertenece al texto del resultado: busca cada canario que plantaste y luego barre cadenas largas de alta entropía que no parezcan un patrón conocido.
Lee la celda que vas a enviar
Cuando copias otra vez desde el panel de resultado, una extensión puede reescribir el portapapeles, o el navegador puede seguir guardando la selección original. Buscar el canario otra vez dentro de la caja de la IA se acerca más al contenido real de salida que un vistazo a la página de ocultar datos.
Comprueba también el tráfico de la propia página
La analítica de FastPwd usa el tracker del propio sitio. En localhost, por defecto, no envía. Los nombres de evento parecen «se ocultaron datos»; según la ficha, no llevan el texto original. Eso sigue siendo una promesa. Buscar el canario en Network convierte «el texto original no se sube ni se escribe en analytics» en una observación de esta pasada. Una comprobación de tráfico más completa está en Cómo comprobar que el cifrado local del navegador no envió el original.
Prepara siempre dos contraseñas falsas: una con sk- o Bearer, para ver que la regla trabaja, y una frase larga al azar, para recordarte que lo que no se enmascaró es lo que de verdad se filtrará.
Cuándo enmascarar, cuándo usar un marcador, cuándo usar Burn-Link
Los tres tratamientos encajan con tres tipos de material. Mezclarlos es como se hace daño la gente.
Teléfonos, correos, documentos y tokens con prefijo sueltos en una frase encajan con el enmascarado por reglas. Quieres «este registro sigue sirviendo para preguntar por una traza», no «entregarle el secreto entero al modelo».
Cuando la pregunta puede cambiar pero el material debe seguir completo, usa un marcador. Cambia una cadena de conexión por postgres://USER:[DB_PASSWORD]@HOST:5432/DB y pregunta por la sintaxis. El modelo no necesita la contraseña real para explicar el formato de un error.
Cuando un secreto completo tiene que llegar a otra persona, no lo pases por una caja de IA. El Burn-Link de FastPwd cifra en este navegador con AES-256-GCM, guarda solo texto cifrado en el servidor y pone la clave detrás de la almohadilla en s.html?id={id}#{key}, de modo que la clave no entra en la petición HTTP por defecto. Crear y leer no piden registro. Una nota cabe en 32 KB; los archivos más grandes van a la caja de cifrado, un archivo de hasta 5 GB. Si pegas el enlace completo en un chat, la protección detrás de la almohadilla desaparece. El detalle está en Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla.
| Material | Tratamiento más adecuado | Qué aspecto tiene «pasar» |
|---|---|---|
| Teléfonos / correos / documentos en un ticket | Ocultar datos por reglas | No queda texto en claro completo; los tipos acertados coinciden con lo que plantaste |
Tokens con sk- o ghp_ |
Ocultar datos por reglas o un marcador | El prefijo puede quedarse; el medio debe llevar asteriscos |
| Contraseñas sin prefijo, códigos de recuperación | Marcador; Burn-Link si alguien debe recibir el valor real | La caja de la IA no contiene ninguno de esos caracteres |
| Un archivo de claves entero | Caja de cifrado; no lo pegues en un chat | Descargas un .lock; en el chat solo queda el nombre del archivo |
Qué puede demostrar esta comprobación, y qué no
La conclusión que sostiene esta comparación es estrecha. Escribirla es lo que te permite alinearte con un compañero.
Puede sostener: en este navegador, en esta pasada, el texto que vas a enviar ya no muestra los canarios en claro que plantaste; las líneas de petición, los cuerpos y los informes de analytics de la página de ocultar datos tampoco contienen ese canario.
No puede sostener: que las reglas cubrieron todos los nombres, direcciones y números de empleado; que el otro producto no guardará el chat para una revisión de seguridad; que una extensión no reescribió el portapapeles; que un resultado oculto equivale a una anonimización jurídica. La limpieza de privacidad de FastPwd deja escrito que esto es una revisión de ayuda. No afirma certificación RGPD ni LOPDGDD.
No tomes «el modelo no ha repetido la contraseña» como prueba de que el envío falló. El contenido que el servidor ya recibió no vuelve a tu pestaña porque la interfaz dibuje asteriscos después.
Preguntas frecuentes
Si desactivo «Improve the model for everyone», ¿el ticket pegado se queda en este equipo?
No. Apagar el entrenamiento solo cambia si el modelo aprende de ese chat. La conversación sigue llegando a los servidores de ese producto y puede aparecer en tu historial. Temporary Chat suele saltarse historial y entrenamiento, pero puede conservarse hasta unos 30 días para vigilar abusos; esto sigue las notas de Data Controls de OpenAI que en septiembre de 2026 seguían vigentes; el resto de productos sigue sus propias condiciones. Ocultar datos apunta al texto de salida, no al interruptor de entrenamiento.
¿El resultado oculto sirve como certificado de cumplimiento o informe de anonimización?
No. El enmascarado por reglas es coincidencia de patrones: puede tapar teléfonos, documentos, correos, API Key habituales e IP, y se saltará un redactado informal o una contraseña sin prefijo fijo. No afirma RGPD, LOPDGDD ni ninguna otra certificación. Antes de enviar, revisa a mano el texto que vas a pegar.
Después de ocultar datos, ¿puedo pegar en la IA una contraseña de base de datos o un código de recuperación enteros?
Casi nunca. Las contraseñas sin prefijo, las cadenas de conexión y los códigos de recuperación suelen no coincidir con ninguna regla. Ese material debe ir por Burn-Link: se cifra en este dispositivo con AES-256-GCM, el servidor solo guarda texto cifrado y la clave va detrás de la almohadilla del enlace. En la caja de la IA deja un marcador, por ejemplo [DB_PASSWORD].
Al ocultar datos en FastPwd, ¿el texto original se sube o se escribe en analytics?
Según la ficha del producto, el análisis y el enmascarado terminan en la pestaña actual. El texto original no se envía como dato de negocio HTTP ni se escribe en analytics. La analítica registra nombres de evento del tipo «se ocultaron datos». Para comprobar esta pasada, busca un canario en Network: no debe aparecer en líneas de petición, cuerpos ni informes de analytics. Al cerrar la pestaña, esa entrada no queda en un servidor de FastPwd, porque nunca llegó allí como dato de negocio.
Recorre los pasos con un ticket falso
Si quieres una página que deja por escrito el límite de cálculo, abre Ocultar datos de FastPwd. Listo para usar, sin registro. Pega el ticket falso de arriba, deja marcados Teléfono, Documento, Tarjeta, Correo, API Key e IP, lee los tipos acertados con la máscara por defecto y luego activa el enmascarado completo y compara otra vez.
Usa el mismo material para un segundo ejercicio: solo cuando las contraseñas falsas que queden se conviertan en marcadores puede el texto entrar en cualquier caja de IA. Cuando un secreto completo debe llegar a un compañero, pasa a Burn-Link. No pegues de vuelta en la IA la dirección completa del enlace y la clave. Si el ticket sigue llevando un enlace corto de campaña, quita utm_*, fbclid y gclid con Limpiar enlace en la misma página antes de decidir si esa URL entra en el prompt.
Estos ejercicios no demuestran que un sitio concreto sea «absolutamente seguro». Te dejan, antes de pulsar enviar, una comparación que un compañero puede leer: canarios, tipos acertados, marcadores y, si hace falta, una pasada por Network. Cambia a cualquier «máscara inteligente» o «pasarela de IA de empresa» y los mismos pasos siguen valiendo.
La próxima vez que envíes, recuerda tres cosas. Primera: lee el texto que vas a enviar, no el texto del botón. Segunda: las reglas cubren campos sueltos; no cubren una contraseña entera. Tercera: un interruptor de entrenamiento cambia cómo la otra parte usa el texto; no cambia el hecho de que los campos ya han salido de este equipo. Una comparación que puedes repetir es la que merece entrar en la norma de tickets de tu equipo.
Para seguir leyendo
Para confirmar que la propia página de ocultar datos no envió el original, pasa el mismo canario por Network: Cómo comprobar que el cifrado local del navegador no envió el original. Cuando un secreto completo debe llegar a una persona y no a un modelo, mira por qué una clave puede ir detrás de la almohadilla: Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla.