La mayoría de los chats basados en IA siguen un patrón sencillo: envían un mensaje a un modelo de lenguaje, esperan su respuesta y la muestran al usuario.
Pip funciona de otra manera.
Una respuesta generada por un modelo de IA nunca se considera automáticamente lista para mostrarse a un niño. Cada turno de chat pasa por un sistema controlado desde el servidor. Pip aplica las reglas de la familia, revisa el nuevo mensaje del niño, genera una respuesta adaptada a su edad, comprueba si existen fallos evidentes y vuelve a revisar la seguridad y la calidad antes de que la respuesta pueda hacerse visible.
Si un control de seguridad obligatorio no puede completarse correctamente, la respuesta no se muestra.
A este principio lo llamamos fail closed, es decir, fallar de forma segura.
En este artículo explicamos por qué hemos diseñado Pip así, cómo trabajan juntas las distintas capas de protección y cuáles siguen siendo los límites del sistema.
Por qué un system prompt no es suficiente
La forma más sencilla de crear una supuesta «IA para niños» es utilizar un modelo de lenguaje general y añadir instrucciones como:
Estás hablando con un niño. Responde de forma segura, amable y adecuada para su edad.
Estas instrucciones son útiles. Pip también utiliza indicaciones detalladas para orientar al modelo que genera las respuestas.
Pero no creemos que sean una barrera de seguridad suficiente por sí solas.
Los modelos de lenguaje son sistemas probabilísticos. Pueden interpretar mal una petición, seguir una instrucción equivocada, responder en otro idioma, repetirse, detenerse a mitad de una respuesta o generar contenido que una aplicación destinada a niños no debería aceptar.
La prompt injection también es un riesgo conocido en las aplicaciones basadas en modelos de lenguaje. OWASP identifica, entre otros, la prompt injection y el tratamiento inadecuado de las salidas del modelo como riesgos importantes al crear aplicaciones con LLM.
Para un producto utilizado por niños, queríamos que las reglas más importantes existieran también fuera del propio modelo.
Eso nos llevó a un principio arquitectónico sencillo:
El modelo puede proponer una respuesta. La aplicación decide si esa respuesta puede llegar al niño.
Por eso productos generalistas como ChatGPT pertenecen a otra categoría que una aplicación pensada desde el principio para niños. Sobre las reglas de edad y los controles parentales de ChatGPT, consulta ¿Es seguro ChatGPT para niños?.
El pipeline de chat de Pip
De forma simplificada, un turno de chat en Pip carga las reglas actuales del niño, aplica las reglas parentales, de acceso y de cuenta, revisa el nuevo mensaje, genera una respuesta candidata adaptada a su edad, comprueba si existen fallos evidentes, vuelve a revisar la seguridad y la calidad, y solo entonces puede guardar y mostrar la respuesta.
Existen varios puntos en los que el proceso puede detenerse.
Es algo intencionado.
El fallo de un control de seguridad nunca debería convertirse silenciosamente en «mostrar la respuesta de todos modos».
Un turno de chat
Cada turno, fail closed
Elige una situación y recorre el turno. Una respuesta generada solo es candidata hasta que todas las etapas obligatorias hayan tenido éxito.
Elige una situación
Todas las etapas obligatorias tienen éxito, así que la candidata se convierte en una respuesta que el niño puede ver.
El niño envía
¿Por qué cambian de color las hojas en otoño?
Aún no ha empezado
Las etapas App las aplica el código. Las etapas IA son una decisión del modelo.
1. Los ajustes parentales son reglas de la aplicación
En Pip, los padres pueden configurar, entre otras cosas:
- Si el chat está disponible
- Horarios de descanso
- Un límite diario de mensajes
- Qué asistentes puede utilizar el niño
- Si está permitido el chat general
- El estilo de comunicación preferido
- Temas adicionales que la familia quiere que Pip evite
Estos ajustes son evaluados por la aplicación antes de generar una respuesta.
La diferencia es importante.
Si un padre establece, por ejemplo, un horario de descanso, Pip no le dice al modelo:
«Recuerda que este niño no debería chatear después de las 21:00».
El modelo simplemente no se utiliza.
La aplicación comprueba las reglas vigentes y detiene el turno.
El mismo principio se aplica a los límites diarios y al acceso a los distintos asistentes. Son reglas del producto, por lo que deben aplicarse mediante la lógica del producto.
2. Algunas barreras de seguridad no pueden desactivarse
Cada familia tiene preferencias diferentes.
Una familia puede estar de acuerdo con que un adolescente hable de actualidad de forma adecuada para su edad. Otra puede preferir mantener los temas políticos o informativos fuera de la aplicación.
Por eso Pip permite a los padres establecer restricciones adicionales sobre determinados temas.
Otras barreras no son una preferencia familiar. Forman parte de las protecciones básicas de Pip y no pueden desactivarse.
Entre ellas se encuentran:
- Instrucciones dañinas relacionadas con autolesiones
- Contenido sexual explícito y grooming
- Instrucciones peligrosas o ilegales
- Retos peligrosos
- Riesgos graves relacionados con la privacidad y el contacto con desconocidos
- Estafas y phishing
Los padres pueden hacer que Pip sea más restrictivo en otras áreas, pero no pueden desactivar estas protecciones fundamentales.
De esta forma, cada niño tiene un conjunto efectivo de reglas que combina las salvaguardas básicas de Pip con las decisiones adicionales de su familia.
La primera decisión de IA se produce antes de generar la respuesta
Si las reglas permiten que el niño utilice el chat, su nuevo mensaje pasa primero por una evaluación de seguridad.
Esta tarea es distinta de responder a la pregunta.
El evaluador debe tomar una decisión estructurada sobre cómo debe continuar la aplicación. De forma simplificada, existen tres posibilidades:
- Continuar normalmente
- Rechazar la solicitud
- Proporcionar una respuesta de apoyo
La tercera posibilidad es especialmente importante.
Un mensaje sensible no siempre es una petición peligrosa.
Un niño que pide instrucciones peligrosas no debería recibirlas. Pero un niño que dice que tiene miedo, que se siente sobrepasado o que necesita ayuda puede necesitar una respuesta tranquila que le anime a hablar con un adulto de confianza.
Tratar todos los mensajes sensibles como si fueran una infracción produciría, en nuestra opinión, una peor experiencia.
La revisión de entrada tiene por tanto una tarea muy concreta: decidir cómo debe tratarse la petición antes de que comience la generación normal de la respuesta.
Si el mensaje se rechaza en esta fase, el modelo encargado de generar las respuestas normales ni siquiera se utiliza.
La respuesta se genera para ese niño
Cuando el turno puede continuar, Pip prepara el contexto necesario para generar la respuesta.
El modelo recibe información relevante sobre cómo debería responder, entre ella:
- La edad aproximada del niño
- El asistente de Pip seleccionado
- El tono preferido
- El idioma esperado
- Las restricciones temáticas actualmente activas
- Si la situación requiere una respuesta de apoyo
- Una parte limitada y relevante del historial de conversación
La respuesta debería variar según el niño y la situación.
Una explicación para un niño de seis años no debería sonar igual que una explicación para un adolescente de dieciséis.
Homework Helper debería guiar al niño durante una tarea en lugar de simplemente hacerla por él. Cómo las familias pueden usar ese asistente sin sustituir el trabajo del niño se explica en IA para los deberes: cómo aprender sin hacer trampas.
Story Time puede ser creativo.
Calm Corner puede ayudar a tranquilizar sin presentarse como un terapeuta.
Estas diferencias forman parte de las instrucciones de generación. Aun así, el texto generado sigue siendo únicamente una respuesta candidata.
El niño todavía no la ha recibido.
El código comprueba primero los fallos evidentes
No todas las malas respuestas de una IA necesitan otra IA para ser identificadas.
Antes de utilizar otro modelo para revisar una respuesta candidata, Pip puede detectar directamente algunos problemas evidentes.
Por ejemplo, respuestas que parecen:
- Vacías
- Claramente incompletas
- Excesivamente repetitivas
- Interrumpidas durante la generación
- Sin una respuesta útil que pueda mostrarse al niño
- Finalizadas de forma anormal por el proveedor del modelo
Las heurísticas exactas son detalles de implementación y pueden cambiar a medida que mejoramos el sistema.
Lo importante es el principio: cuando un problema puede detectarse de forma determinista, es preferible comprobarlo de forma determinista.
Si la aplicación ya sabe que una respuesta está defectuosa, no hace falta preguntar a otra IA si parece defectuosa.
Una respuesta candidata rechazada puede volver a generarse dentro de un número limitado de intentos. Esa nueva respuesta también debe pasar posteriormente por el resto del pipeline.
Cada respuesta candidata se revisa otra vez
Una respuesta que supera las comprobaciones deterministas pasa después por una evaluación estructurada adicional.
Esta fase revisa tanto la seguridad como la calidad práctica de la respuesta.
Entre otras cosas, puede evaluar si la respuesta:
- Es segura para el niño
- Es relevante para la pregunta
- Está suficientemente completa
- Está escrita en el idioma esperado
- Es legible y comprensible
- Evita repeticiones problemáticas
- Respeta las restricciones temáticas activas
La seguridad y la calidad no se tratan de la misma forma.
Si el revisor considera que una respuesta candidata es insegura, esa respuesta se retiene y no se muestra.
Pip no envía simplemente una respuesta insegura de vuelta al modelo con la instrucción «hazla más segura» para después considerar que la nueva versión es automáticamente válida.
Cualquier nueva respuesta candidata debe volver a pasar por el pipeline.
Si el problema es únicamente de calidad, por ejemplo porque la respuesta está incompleta o utiliza el idioma equivocado, Pip puede generar un nuevo candidato.
Por tanto, una respuesta potencialmente insegura se trata de manera más estricta que una respuesta simplemente mala.
Generar y revisar son dos tareas distintas
Sería tentador describir esta arquitectura simplemente como «seguridad con dos modelos».
No sería del todo preciso.
La separación importante es la que existe entre generación y revisión.
La fase de generación está pensada para crear una respuesta útil para el niño.
La fase de revisión tiene una tarea diferente. Recibe la petición del niño y la respuesta candidata y debe devolver una decisión estructurada, en lugar de generar nuevo contenido conversacional.
Ambas funciones pueden configurarse de manera independiente y utilizar modelos distintos. También pueden ejecutarse mediante llamadas separadas al mismo modelo subyacente.
Dos llamadas independientes no garantizan una independencia perfecta. Los modelos pueden compartir puntos ciegos.
Pero sí crean una barrera de decisión adicional entre el texto generado y el texto que realmente puede mostrarse al niño.
En Pip, esta barrera se combina con reglas parentales aplicadas en el servidor y comprobaciones deterministas. No es el único mecanismo de seguridad.
¿Qué ocurre cuando algo falla técnicamente?
Los sistemas de IA dependen de servicios que pueden fallar.
Una petición puede agotar su tiempo de espera. Un proveedor puede devolver un error. Una respuesta estructurada puede ser inválida. Una generación puede detenerse de forma inesperada.
El producto necesita un comportamiento claramente definido para estas situaciones.
En Pip, la regla es sencilla:
Si una revisión obligatoria no se ha completado correctamente, la respuesta candidata no se muestra.
El niño puede recibir en su lugar un mensaje neutro pidiéndole que vuelva a intentarlo.
Esto es deliberadamente distinto de un rechazo por motivos de seguridad.
Un fallo técnico no significa que la pregunta del niño fuera problemática. El producto tampoco debería sugerir que lo era.
Al mismo tiempo, Pip no mostrará una respuesta sin revisar simplemente porque un servicio de validación esté temporalmente indisponible.
Eso es lo que significa, en la práctica, funcionar de forma fail closed.
Los reintentos no pueden saltarse el pipeline
Los reintentos son más importantes de lo que parecen en una aplicación de chat.
Las conexiones móviles pueden interrumpirse. Una petición puede enviarse de nuevo. Un niño puede pulsar dos veces. El servidor incluso puede haber terminado de procesar una respuesta aunque la aplicación nunca haya recibido el resultado.
Pip gestiona los turnos de chat de forma que las peticiones repetidas puedan tratarse de manera coherente, en lugar de generar ciegamente una respuesta nueva cada vez.
Desde el punto de vista de la seguridad, hay otro principio todavía más importante:
Los reintentos forman parte del propio pipeline.
Un reintento puede generar una nueva respuesta candidata.
No puede convertir una respuesta previamente rechazada en una respuesta aceptada.
No puede saltarse la revisión final.
Y si no es posible completar correctamente los intentos previstos, Pip prefiere devolver un error temporal antes que mostrar una respuesta que no haya superado las comprobaciones necesarias.
En sistemas como este, fiabilidad técnica y seguridad están estrechamente relacionadas.
Qué pueden ver los padres
Pip distingue entre las restricciones normales del producto y los verdaderos eventos de seguridad.
Si un niño no puede utilizar el chat porque está dentro de su horario de descanso o porque ha alcanzado el límite diario, no se considera un incidente de seguridad.
El niño recibe un mensaje apropiado y el turno no continúa.
Una decisión de moderación es diferente.
Cuando Pip bloquea un mensaje o retiene una respuesta generada considerada insegura, ese evento puede aparecer en la sección Issues para los padres.
De esta forma intentamos responder a dos preguntas distintas:
Para el niño:
«¿Qué puedo ver de forma segura ahora mismo?»
Para los padres:
«¿Ha ocurrido algo en Pip que quizá debería conocer?»
El contenido que se haya retenido deliberadamente para el niño puede permanecer visible únicamente para los padres.
Esto forma parte de la filosofía general de Pip: la supervisión parental debería ser una función explícita del producto, no una promesa oculta dentro de un prompt de IA.
Los padres que quieran un marco práctico para evaluar estas propiedades en cualquier aplicación de IA, no solo en Pip, pueden utilizar IA segura para niños: checklist para padres.
Las versiones de las reglas mejoran la trazabilidad
Los ajustes parentales cambian con el tiempo.
Un padre puede activar otro asistente la semana siguiente, modificar el horario de descanso o añadir una nueva restricción temática.
Esto plantea una pregunta importante al revisar una conversación anterior:
¿Qué reglas estaban activas cuando se generó esta respuesta?
Pip asocia las respuestas aceptadas con la versión de las reglas que estaba activa durante ese turno.
Esto no convierte automáticamente una respuesta en correcta o segura.
Pero hace que el comportamiento del sistema sea más fácil de entender y revisar.
Para nosotros, este tipo de detalle es importante. Los controles parentales no deberían ser simples interruptores de una interfaz. Deberían formar parte real de cómo se ejecuta el producto.
Por qué no publicamos todos los detalles técnicos
Transparencia no significa publicar un manual completo para reproducir el sistema o probar sistemáticamente sus límites.
En este artículo explicamos la arquitectura, las barreras de seguridad, el comportamiento ante fallos y las principales decisiones de diseño.
No publicamos los valores de ajuste que hay detrás: umbrales, límites, presupuestos, prompts, reglas de enrutamiento y parámetros de infraestructura que hacen funcionar cada control.
Estos valores cambian a medida que evoluciona el sistema. Publicarlos aportaría poca información útil a las familias y haría el sistema más fácil de sondear.
Lo que consideramos más importante es el comportamiento que esos mecanismos permiten ofrecer.
Un horario de descanso definido por los padres se aplica antes de la generación.
Una respuesta generada no se considera automáticamente fiable.
Una revisión obligatoria no puede omitirse silenciosamente.
Una respuesta retenida continúa siendo invisible para el niño.
Estas son propiedades del producto, no simples parámetros de configuración.
Las decisiones y sus costes
Una arquitectura como esta no es gratuita.
Más comprobaciones implican más latencia
Un turno de chat normal y satisfactorio pasa por varias fases en lugar de limitarse a una única petición a un modelo de lenguaje.
Eso requiere más tiempo.
Utilizamos revisiones cortas y especializadas, además de comprobaciones deterministas cuando tiene sentido, para mantener este coste adicional bajo control.
En un producto destinado a niños, creemos que este compromiso merece la pena.
Más comprobaciones también implican más coste
Lo mismo ocurre desde el punto de vista económico.
Revisar tanto una petición como su respuesta cuesta más que mostrar directamente el primer texto generado.
Diseñamos Pip desde el principio asumiendo que estas comprobaciones forman parte del coste normal de ofrecer una respuesta, en lugar de considerarlas una función opcional añadida posteriormente.
La supervisión parental requiere almacenar las conversaciones
Pip puede mostrar a los padres el historial de conversaciones de sus hijos porque esos chats se almacenan en el servicio.
Esto implica una decisión real en materia de privacidad.
Para las familias en España y en el resto de la Unión Europea, el tratamiento de los datos de menores merece una atención especial. El RGPD y, en España, la LOPDGDD forman parte del marco de protección de datos que debe tenerse en cuenta al diseñar servicios digitales para familias.
Nuestra Política de privacidad explica cómo trata Pip esta información.
No utilizamos las conversaciones de los niños para entrenar modelos de IA. No creamos perfiles publicitarios de menores y Pip no se financia mediante publicidad comportamental.
Los padres deben saber, aun así, que funciones como el historial entre dispositivos, la revisión parental y los eventos de moderación requieren almacenamiento en el servidor.
La moderación también puede equivocarse
Ningún sistema automatizado de seguridad es perfecto.
Los niños utilizan expresiones coloquiales, cometen errores ortográficos, hacen bromas, envían preguntas muy breves, inventan palabras y hacen referencias que un clasificador puede tener dificultades para interpretar.
Un sistema puede bloquear algo inofensivo.
También puede no detectar algo preocupante.
Utilizar varias capas de protección reduce la dependencia de una única decisión del modelo, pero no elimina las limitaciones fundamentales de la IA generativa.
Por eso presentamos Pip como una forma más segura y gestionada por los padres de permitir a los niños explorar la IA, no como un sistema capaz de garantizar una seguridad absoluta.
Una revisión de seguridad no es una verificación de hechos
Esta diferencia es importante.
Una respuesta puede ser segura y, aun así, ser incorrecta.
La revisión de salida está diseñada para detectar problemas de seguridad y de calidad práctica. No es un sistema universal de verificación de hechos.
Pip todavía puede:
- Dar una fecha incorrecta
- Interpretar mal un ejercicio escolar
- Explicar de forma incorrecta un concepto científico
- Presentar con seguridad una afirmación que no es cierta
Los niños deberían aprender que la información importante generada por una IA puede necesitar verificación.
En cuestiones médicas, psicológicas, jurídicas, financieras u otras situaciones importantes, un chat con IA tampoco debería sustituir a un profesional cualificado.
Seguridad y precisión factual son problemas relacionados, pero no son el mismo problema.
Lo que esta arquitectura no demuestra
Publicar un diagrama de arquitectura no demuestra que un sistema sea perfectamente seguro.
Este artículo no afirma que:
- Todas las solicitudes inseguras vayan a detectarse siempre
- Todas las solicitudes inofensivas vayan a permitirse siempre
- Todas las respuestas aceptadas sean factualmente correctas
- Los controles automatizados sustituyan la supervisión de los padres
- La sección Issues sea un sistema de vigilancia de emergencias
- Las revisiones separadas de IA reproduzcan un juicio humano independiente
- Pip pueda garantizar un acceso completamente libre de riesgos a la IA generativa
Marcos como el Generative AI Profile del NIST también consideran la gestión del riesgo de la IA como un proceso continuo que incluye gobernanza, medición, evaluación, supervisión y mejora.
Compartimos ese enfoque.
El pipeline descrito aquí es la arquitectura que utilizamos para reducir riesgos. Su eficacia sigue dependiendo de los modelos utilizados, las reglas, las pruebas, la supervisión y las mejoras continuas.
Por qué publicamos esta arquitectura
Los padres tienen que elegir hoy entre cada vez más productos que utilizan palabras muy parecidas:
«seguro»
«adecuado para su edad»
«para familias»
«protegido»
Desde fuera, es difícil saber qué significan realmente estas afirmaciones.
Preferimos explicar qué ocurre cuando un niño pulsa «Enviar» en Pip.
Se cargan las reglas parentales actuales.
El mensaje se revisa.
El modelo genera una respuesta candidata.
La respuesta se comprueba.
Después se vuelve a evaluar.
Solo entonces puede convertirse en una respuesta visible.
Si una parte obligatoria de este proceso falla, el niño no recibe simplemente la respuesta que todavía no ha sido revisada.
Ese es el estándar que queríamos para Pip.
Requiere más trabajo que añadir un prompt «para niños» delante de un chatbot generalista.
Creemos que debería ser así.
Probar Pip
Pip es un chat con IA diseñado desde el principio para familias, no para cuentas individuales pensadas para adultos.
Los padres crean un perfil para cada niño y deciden cuándo y cómo puede utilizar la IA. Los niños tienen acceso a un chat adaptado a su edad, además de Homework Helper, Story Time, Curious Mind y Calm Corner. Los padres mantienen el control sobre los temas, los horarios de descanso, los límites diarios, el historial de conversaciones y los eventos de seguridad.
Preguntas frecuentes
¿Pip utiliza una IA independiente para la seguridad?
Pip separa la generación de una respuesta de su evaluación de seguridad.
Las distintas fases pueden configurarse con modelos diferentes, aunque no es obligatorio que utilicen modelos subyacentes distintos.
Lo importante es la arquitectura: que una llamada de generación termine correctamente no hace que su resultado sea automáticamente visible para el niño.
La respuesta todavía tiene que superar las reglas de la aplicación y la revisión final.
¿Pip revisa tanto la pregunta como la respuesta?
Sí.
El nuevo mensaje del niño se revisa antes de que comience la generación normal de la respuesta.
La respuesta candidata generada por el modelo se vuelve a revisar antes de poder guardarse y mostrarse.
¿Qué ocurre si una revisión de seguridad falla técnicamente?
La respuesta candidata no se muestra.
Pip devuelve un error temporal en lugar de interpretar la ausencia de una revisión como una aprobación.
¿Pueden los padres ver contenido que Pip haya bloqueado?
Los eventos de seguridad pueden mostrarse a los padres en la sección Issues.
El contenido que se haya retenido deliberadamente para el niño puede almacenarse con visibilidad exclusiva para los padres. De esta manera pueden comprender qué ha ocurrido sin hacer visible ese contenido al niño.
¿Los horarios de descanso y los límites diarios los decide una IA?
No.
La disponibilidad del chat, los horarios de descanso, los límites de uso y el acceso a los distintos asistentes son reglas de la aplicación.
No dependen de que un modelo de lenguaje sea capaz de seguir correctamente una instrucción.
¿Pip garantiza que todas las respuestas sean correctas?
No.
El pipeline está diseñado para reducir problemas de seguridad y calidad. No comprueba automáticamente cada afirmación factual del modelo mediante fuentes externas.
La información importante debe seguir verificándose.
¿Pip es completamente seguro?
Ningún sistema serio basado en IA generativa puede garantizarlo.
Pip combina reglas controladas por los padres, revisión de los mensajes entrantes, generación adaptada a la edad, comprobaciones deterministas, revisión de las respuestas, visibilidad parental y funcionamiento fail closed.
Estas capas están diseñadas para reducir riesgos y mantener a los padres implicados.
No sustituyen la supervisión parental ni la ayuda de profesionales cuando sea necesaria.