La primera pregunta debe llegar antes que la herramienta. Ante una respuesta automática, la cuestión inicial no es cuánto tiempo ahorra, cuántos mensajes clasifica ni qué apariencia de inteligencia ofrece. La cuestión es qué necesidad atiende, qué daño puede causar si se equivoca, quién tendrá una salida cuando no entienda la respuesta y quién responderá por la decisión. Este manifiesto propone una regla sencilla para la inteligencia artificial cotidiana: ninguna automatización debe ocupar el lugar de una pregunta humana bien formulada.

La automatización ya interviene en gestos corrientes. Ordena correos, recomienda horarios, filtra solicitudes, redacta borradores, traduce avisos y decide qué información aparece primero. Por esa cercanía parece neutral. Sin embargo, cada respuesta automática fija prioridades, presupone datos y convierte una situación compleja en una categoría. El problema no reside solamente en los grandes sistemas ni en los titulares extraordinarios. Está también en la respuesta breve que llega a una persona preocupada, en el formulario que interpreta una ausencia como error y en el asistente que ofrece una solución convincente sin conocer el contexto.

Preguntar antes de automatizar#

La pregunta previa debe describir el problema sin vender una respuesta de antemano. Puede ser: «¿qué tarea se está retrasando y por qué?», «¿qué información necesitan realmente las personas?», «¿qué parte requiere juicio, empatía o responsabilidad?». Preguntar así evita que una herramienta se convierta en la definición del problema. Si una oficina recibe muchas consultas repetidas, quizá sea útil mejorar una página, aclarar una carta o ampliar un horario de atención. Instalar un chatbot puede ser adecuado en algunos casos, pero no es la respuesta automática por defecto.

La pregunta previa debe describir el problema sin vender una respuesta de antemano.

Una buena pregunta también nombra el límite. Hay decisiones que no deberían delegarse en un sistema que infiere patrones: una urgencia sanitaria, una solicitud de apoyo social, una denuncia de discriminación o una situación laboral delicada requieren personas capaces de escuchar, pedir aclaraciones y asumir responsabilidad. La rapidez puede ser valiosa, pero no equivale a cuidado. Cuando el coste de un error recae sobre quien ya tiene menos tiempo, menos recursos o menos acceso a ayuda, el estándar debe ser más alto.

Antes de poner una herramienta en marcha conviene escribir una ficha breve: propósito concreto, personas afectadas, datos usados, respuesta prevista, riesgos conocidos, vía humana y fecha de revisión. Esta ficha no necesita lenguaje técnico para ser útil. Su función es obligar a que la promesa de eficiencia se enfrente con las condiciones de uso. También permite explicar a quien recibe el servicio por qué existe una automatización y qué puede hacer si no funciona. Una herramienta sin propósito delimitado tiende a expandirse hacia tareas para las que no fue evaluada.

Caso 1: el mensaje que parecía una resolución#

Una entidad de vivienda incorporó un asistente para responder preguntas frecuentes sobre ayudas al alquiler. El sistema reconocía palabras como «documentos», «plazo» y «rechazo», y devolvía enlaces a sus páginas informativas. En las primeras semanas redujo parte de las llamadas. Después, varias personas interpretaron sus respuestas como una resolución oficial: al leer que faltaba un justificante, dejaron de presentar la solicitud; al leer que un plazo había terminado, no preguntaron por una excepción prevista en la norma. La frase automática era clara, pero carecía de autoridad para cerrar esas situaciones.

La revisión empezó con una pregunta distinta: «¿qué necesita saber una persona para no perder un derecho por interpretar mal una respuesta?». Se cambió el texto de apertura para aclarar que la herramienta ofrecía orientación general, no decisiones. Las preguntas sobre denegaciones, plazos vencidos y documentación incompleta pasaron directamente a un canal atendido por personal. Cada respuesta automática incluyó la fecha de actualización de la información y un enlace visible para solicitar revisión. Durante dos meses se revisaron los contactos derivados, las solicitudes abandonadas y las correcciones hechas por el equipo.

El caso muestra que la transparencia no consiste en añadir una etiqueta diminuta que diga «generado por IA». Consiste en diseñar la respuesta para que nadie tenga que adivinar su alcance. Si una frase puede influir en el acceso a un derecho, debe indicar lo que sabe, lo que no sabe y cómo obtener una comprobación humana. La automatización siguió prestando una función limitada, pero dejó de aparentar una decisión que no podía tomar.

Caso 2: la prioridad calculada que ocultaba una urgencia#

Un servicio de mantenimiento utilizó un sistema para ordenar avisos recibidos desde una aplicación. El modelo daba prioridad a las incidencias con ciertas palabras y a las zonas con más reportes recientes. La intención era organizar mejor el trabajo. No obstante, un aviso sobre una rampa dañada quedó abajo porque su descripción era breve y no coincidía con los términos asociados a riesgo. Quien lo envió escribió desde un teléfono con poca batería y no adjuntó una fotografía. La clasificación pareció objetiva, aunque había convertido una falta de detalles en una falta de importancia.

La pregunta correcta no era «¿cómo se mejora la puntuación del modelo?», sino «¿qué clase de aviso no puede esperar a que el modelo esté seguro?». Se definieron categorías de seguridad que nunca se resolvían solo por clasificación automática. Los avisos ambiguos se colocaban en una cola de revisión rápida, y la aplicación permitía marcar una barrera física con pocas palabras o mediante una llamada. El equipo publicó el criterio de prioridad y conservó un registro de los cambios, sin almacenar más datos personales de los necesarios.

La corrección no eliminó toda automatización. La usó como apoyo para ordenar trabajo repetitivo, no como permiso para ignorar incertidumbre. Además, se midieron los tiempos de revisión de alertas ambiguas, las incidencias reabiertas y los avisos que llegaron por canales alternativos. Un sistema responsable no presume de conocer el mundo con una puntuación. Reconoce cuándo le falta contexto y entrega la situación a alguien que puede obtenerlo.

Caso 3: el borrador rápido que cambió el tono#

Un equipo de atención comenzó a usar una herramienta generativa para redactar respuestas a reclamaciones. El borrador ahorraba minutos y mantenía un estilo ordenado. Sin embargo, varias contestaciones empezaron a repetir fórmulas como «lamentamos las molestias» junto a explicaciones demasiado seguras sobre hechos que aún se investigaban. Algunas personas recibieron un texto correcto en gramática y frío en sentido: no reconocía la dificultad concreta ni explicaba qué ocurriría después. La velocidad de escritura había desplazado la responsabilidad de comprobar el contenido.

El equipo acordó que ningún borrador podía enviarse sin lectura humana y que las reclamaciones con daño, urgencia o posible discriminación no se redactarían mediante plantillas generativas. Se creó una lista de comprobación: confirmar hechos, retirar afirmaciones no verificadas, usar lenguaje claro, indicar el siguiente paso y nombrar una persona o canal de respuesta. Las muestras se revisaban de forma periódica para detectar errores, tono inadecuado y referencias inventadas. También se informó al equipo de que el uso de la herramienta no servía para medir productividad individual.

La lección no es que un borrador sea siempre inaceptable. Es que un texto automático no tiene la obligación moral ni administrativa de responder por sus palabras. Esa obligación sigue siendo institucional. Un buen proceso aprovecha la ayuda mecánica para tareas de bajo riesgo y conserva tiempo humano para escuchar, contrastar y reparar. Cuando una organización responde con una máquina, debe poder explicar quién revisó la respuesta y cómo puede corregirse.

Diseñar salidas, no callejones#

Toda respuesta automática debe incluir una salida clara. No basta con un botón escondido ni con una dirección genérica que nunca recibe contestación. La salida debe ser accesible desde el mismo momento en que aparece la respuesta, funcionar en móvil, admitir lenguaje sencillo y no exigir repetir toda la historia. Puede consistir en hablar con una persona, pedir revisión, guardar el caso para después o usar un canal no digital. Elegir una vía humana no debe tratarse como un fracaso del usuario ni como una excepción costosa que haya que desalentar.

Las salidas importan especialmente cuando el sistema trabaja con datos incompletos. Un modelo puede confundir nombres, interpretar mal una expresión local, no reconocer una necesidad de accesibilidad o responder con información antigua. La persona afectada no tiene por qué saber qué error técnico ocurrió para pedir ayuda. Basta con que pueda decir «esto no responde a mi situación». Esa frase debe abrir una revisión, no otro bucle de opciones automáticas.

La accesibilidad forma parte de esta responsabilidad. Una interfaz que solo acepta texto largo excluye a quien necesita llamar; una explicación con palabras técnicas excluye a quien no conoce el procedimiento; un plazo breve excluye a quien depende de apoyo. Es necesario probar las respuestas con diferentes dispositivos, idiomas, lectores de pantalla, conexiones y circunstancias de tiempo. La prueba no busca medir la habilidad de las personas. Busca descubrir dónde el servicio pide una carga innecesaria y cómo puede reducirla.

También se requiere protección de datos. La comodidad de pegar una consulta completa en una herramienta externa puede exponer información que no era necesaria para obtener un borrador. Deben usarse solo los datos indispensables, explicarse la finalidad, limitarse los accesos y establecerse plazos de conservación. Las conversaciones sensibles no deben convertirse en material de entrenamiento o evaluación sin una base clara y una información comprensible. La minimización no es un obstáculo para la innovación: es una manera de impedir que una respuesta útil hoy genere un riesgo silencioso mañana.

Gobernar la respuesta cotidiana#

Gobernar no significa producir un documento extenso que nadie consulta. Significa asignar responsabilidades visibles. Cada herramienta necesita una persona o equipo responsable de su propósito, de sus actualizaciones y de la recepción de incidencias. Debe existir un calendario de revisión proporcional al riesgo y una forma de pausar el sistema si aparecen errores graves. Los registros deben permitir reconstruir qué versión se usó, qué reglas estaban activas y cómo se corrigió una respuesta, sin convertir el seguimiento en vigilancia de usuarios o trabajadores.

La evaluación debe mirar más que la precisión técnica. Conviene preguntar cuántas personas encontraron una salida humana, cuántas respuestas fueron corregidas, quién abandonó el proceso, qué grupos tuvieron más dificultades y qué daño se evitó gracias a una revisión. Los números no explican por sí solos las causas, por lo que deben combinarse con conversaciones voluntarias y seguras. Si una automatización reduce tiempo para la mayoría pero aumenta barreras para una minoría, ese resultado no es un éxito completo.

La información pública debe ser proporcional y comprensible. Una organización puede explicar qué tarea apoya el sistema, qué datos utiliza en términos generales, qué decisiones no toma y cómo solicitar revisión. No necesita revelar detalles que faciliten abusos, pero tampoco puede pedir confianza ciega. La explicación sirve para corregir expectativas, detectar errores y permitir un debate informado. La opacidad suele proteger a la herramienta; la transparencia útil protege a las personas.

Este manifiesto defiende una práctica concreta: detenerse antes de añadir inteligencia artificial a un flujo de trabajo y formular la pregunta que la herramienta no puede formular por sí misma. ¿A quién ayuda? ¿A quién puede perjudicar? ¿Qué sucede cuando falla? ¿Quién escucha? ¿Cuándo se revisará? Las respuestas no siempre llevarán a automatizar. A veces llevarán a simplificar una norma, contratar apoyo, mejorar un texto o mantener una conversación. Esa posibilidad no es un retraso: es la condición de una decisión responsable.

Fuentes institucionales para sostener este criterio.

El NIST AI Risk Management Framework ofrece un marco para gobernar, mapear, medir y gestionar riesgos de sistemas de inteligencia artificial. La OCDE recoge principios sobre sistemas robustos, transparentes y centrados en las personas. La Comisión Europea explica el marco regulador europeo de inteligencia artificial. La UNESCO presenta su recomendación sobre la ética de la inteligencia artificial y la protección de derechos.

Estas fuentes no sustituyen la responsabilidad de cada servicio. Ofrecen un lenguaje común para reconocer riesgos, documentar decisiones y revisar consecuencias. La práctica decisiva sigue siendo local: escuchar a quienes reciben la respuesta, permitir que cuestionen una clasificación y cambiar el proceso cuando la evidencia lo exige. La inteligencia artificial cotidiana será más digna de confianza cuando no se presente como una autoridad inevitable, sino como una ayuda limitada, revisable y situada.

La primera pregunta debe llegar antes que la herramienta porque una respuesta automática nunca está sola. Lleva consigo una elección sobre tiempo, atención, datos y poder. Formular esa pregunta abre espacio para el cuidado; omitirla deja que la herramienta decida qué problema merece existir. El manifiesto termina donde debe empezar cada proyecto: con una pregunta suficiente para proteger a las personas antes de acelerar el sistema.