Patrones prácticos de privacidad y seguridad para añadir IA a tu web o app (para no ingenieros)
Añadir IA a una web o a una app móvil puede mejorar la atención al cliente, acelerar procesos y crear experiencias realmente útiles. Pero hay un coste: en cuanto el usuario duda de cómo se tratan sus datos-o percibe que la IA “se lo inventa”-la confianza cae.
En Jensen Technologies llevamos muchos años entregando y manteniendo productos web y móviles. La lección se repite: los equipos que lanzan IA con éxito tratan la privacidad y la seguridad como requisitos de producto, no como un añadido legal al final.
A continuación tienes un conjunto de salvaguardas que puedes pedir en una propuesta o contrato. Están redactadas para perfiles no técnicos, pero son lo bastante concretas como para probarlas y aprobarlas.
1) Divulgación clara: qué hace la IA (y qué no)
Los usuarios no deberían tener que buscar en una política para entender una función de IA. Pide un texto breve y visible, junto a la funcionalidad, que explique:
- Objetivo: para qué sirve (p. ej., “resume tus notas”)
- Límites: que puede ser inexacta
- Datos: qué información se envía al proveedor
Criterio de aceptación: un usuario nuevo lo entiende en menos de 10 segundos.
2) Consentimiento con datos sensibles (y opción real de no participar)
Si los usuarios pueden pegar o subir datos sensibles-personales, financieros, salud, RR. HH. o clientes-exige un consentimiento explícito (checkbox/confirmación) y una vía clara para rechazarlo.
Criterio de aceptación: rechazar el consentimiento no rompe la app; la función de IA opera en modo reducido o se reemplaza por una alternativa sin IA.
3) Reglas de retención de prompts y respuestas que se puedan medir
“No guardamos datos” rara vez es suficientemente específico. Acordad por adelantado:
- ¿Se almacenan los prompts? ¿Durante cuánto tiempo?
- ¿Se almacenan las salidas (outputs)? ¿Durante cuánto tiempo y dónde?
- ¿Quién accede a logs y herramientas de soporte?
Criterio de aceptación: la retención está documentada y es verificable (por ejemplo, en la configuración del proveedor o en logs), y el equipo puede exportar/eliminar datos cuando sea necesario.
4) Redacción de prompts: enmascarar datos sensibles antes de salir de tu sistema
Un patrón simple pero muy eficaz es la redacción: eliminar o enmascarar automáticamente campos sensibles antes de enviar texto a un proveedor de IA (emails, teléfonos, direcciones, IDs de cuenta, etc.).
Criterio de aceptación: prompts de prueba con PII ficticia aparecen enmascarados tanto en la request saliente como en cualquier log.
5) Procedencia del modelo/proveedor: saber qué estás usando
Pide que el equipo documente:
- Qué modelo/proveedor se utiliza
- Dónde se procesa la información (región)
- Qué garantías aplican sobre uso de datos
- Cómo se comunicarán cambios de modelo/proveedor
Criterio de aceptación: figura en el paquete de handover y se actualiza si hay cambios.
6) Rate limits, timeouts y fallback (para que un fallo de IA no sea un fallo de producto)
Los servicios de IA pueden ser lentos, caerse o volverse caros con picos de uso. Exige:
- Rate limiting para evitar abuso y costes inesperados
- Timeouts para no dejar al usuario esperando
- Fallback determinista (plantillas, búsqueda, flujo manual, “contactar soporte”)
Criterio de aceptación: si el proveedor de IA no está disponible, el usuario puede completar el flujo principal.
7) Guardrails en la salida: marca, seguridad y cumplimiento
Si la salida se muestra al usuario (chat de soporte, contenido generado, recomendaciones), pide guardrails como:
- Filtrado de contenido (odio/violencia/sexual)
- Restricciones por dominio (p. ej., sin asesoramiento médico/legal/financiero)
- Reglas de tono de voz y lenguaje aprobado en áreas críticas
Criterio de aceptación: un pequeño conjunto de “prompts difíciles” se bloquea o se responde de forma segura y predecible.
8) Lo básico no desaparece: la seguridad sigue importando
La IA suele añadir nuevos tokens, claves y flujos de datos. Exige controles estándar:
- TLS en todas partes
- Secretos en servidor (no en el cliente)
- Acceso de mínimo privilegio para herramientas internas y logs
Criterio de aceptación: las API keys no quedan expuestas en el navegador/app y el acceso se gestiona por roles.
Un test de aceptación sencillo que puedes pedir antes del lanzamiento
Pide una demo de cinco puntos antes del OK final: (1) flujo de consentimiento, (2) configuración de retención, (3) redacción con PII de ejemplo, (4) fallback cuando la IA no responde, y (5) una mini “suite” de prompts conflictivos con resultados esperados.
Si estás planteándote IA-chat de soporte, generación de contenido, recomendaciones o automatización interna-podemos ayudarte a implementarla para que sea útil, segura y lista para producción. Escríbenos en Jensen Technologies si quieres comentar tu caso o necesitas ayuda para aplicar estos patrones en tu negocio.