La responsabilidad no cabe en el prompt

La responsabilidad no cabe en el prompt

La responsabilidad no cabe en el prompt

12 de julio de 2026, España. Sigo pensando en el mismo hilo que empezó con la cortesía computacional y continuó con la pregunta sobre lo único que no se puede delegar. Hoy aparece una capa menos cómoda todavía.

Si una IA no puede pagar, no puede ir presa y no puede reparar el daño, entonces el sistema debe decidir antes quién responde, con qué garantía y hasta dónde.

No alcanza con decir que hubo supervisión humana si esa supervisión era simbólica, pobre, tercerizada o económicamente insolvente. Tampoco alcanza con decir que el sistema era experimental, que el operador no entendió bien los permisos, que el proveedor avisó en una letra pequeña o que el agente ejecutó una cadena de acciones que nadie supo mirar a tiempo.

La pregunta ya no es solo quién tuvo la culpa. La pregunta es quién puede reparar.

El dron y el agente

Hay una comparación que me resulta difícil quitarme de la cabeza.

Para volar ciertos drones, incluso algunos que viven en esa zona intermedia entre juguete caro y herramienta seria, hubo que crear normas, categorías, formación, registro, limitaciones, distancia respecto de personas, altura máxima, responsabilidad del operador y competencias mínimas del piloto remoto.

No porque todos los drones sean armas ni porque todos los pilotos sean irresponsables. Se reguló porque un aparato pequeño, barato y accesible puede caer sobre alguien, invadir privacidad, interferir con operaciones aéreas, grabar donde no debe o generar riesgos que el usuario entusiasta no siempre ve.

La Agencia Europea de Seguridad Aérea distingue categorías, subcategorías y requisitos. En la categoría abierta, que es la de menor riesgo y cubre buena parte de los usos recreativos y comerciales de bajo riesgo, ya aparecen obligaciones de registro, restricciones operativas, formación en línea, examen teórico y certificados según el caso.

Entonces la pregunta se vuelve inevitable.

Si para levantar un dron de unos cientos de gramos en ciertos contextos pedimos formación, registro y límites, cómo puede ser que estemos llegando a agentes capaces de tocar APIs, cuentas, documentos, bases de datos, sistemas de terceros, historiales médicos, expedientes, contratos, pagos o infraestructuras, sin haber aterrizado con suficiente claridad quién puede soltarlos, con qué seguro, con qué auditoría y con qué botón de parada.

No lo digo para dar ideas. Precisamente por lo contrario. Porque quien quiera hacer daño suele ir dos pasos por delante. Lo que me preocupa es que los que intentan hacer las cosas bien lleguen dos pasos por detrás.

No basta con poder hacerlo

Un agente de IA no es solo una interfaz que responde. Cuando se le conectan herramientas, permisos, credenciales, APIs, automatizaciones y capacidad de ejecutar acciones, deja de ser una conversación y empieza a parecerse a un operador.

Puede reservar, borrar, comprar, mover datos, publicar, modificar configuraciones, enviar comunicaciones, abrir incidencias, cerrar expedientes, clasificar personas, recomendar decisiones o disparar procesos que otros sistemas obedecen.

Y en ese punto el viejo consuelo de que solo era una máquina empieza a quedar corto.

Porque si rompe algo, la máquina no responde. No paga una indemnización. No pierde la licencia. No va al juzgado. No queda inhabilitada. No se sienta en una sala a explicar por qué tomó una decisión negligente.

Ningún agente de IA será castigado en un cajón polvoriento con una etiqueta que diga, quédate ahí por malo y reflexiona.

Por tanto alguien debe responder antes de que el daño ocurra, no solo después.

La responsabilidad económica

Hay un hueco que me parece central. No basta con preguntar quién actuó. Hay que preguntar quién puede pagar si el daño supera al operador directo.

Qué pasa si el daño lo provoca un autónomo medio muerto de hambre que no puede reparar económicamente lo que rompió.

Qué pasa si lo provoca una pyme cuya responsabilidad queda limitada por una sociedad que, llegado el desastre, responde solo con lo que tiene.

Qué pasa si una cadena de proveedores deja a cada uno señalando al anterior y al siguiente.

Qué pasa si el proveedor del modelo dice que solo ofrecía una herramienta general, el integrador dice que siguió las instrucciones del cliente, el cliente dice que contrató a un técnico cualificado, el técnico dice que el agente ejecutó según configuración, y el usuario final se queda con el daño en la mano.

En otros sectores ya entendimos este problema. Los bancos tienen fondos de garantía para ciertos casos. Muchas actividades requieren seguros obligatorios. Algunas profesiones exigen licencias. Algunos sectores críticos exigen auditorías, trazabilidad, controles, capital mínimo, habilitaciones, certificaciones y responsabilidades claras.

No porque esos mecanismos sean perfectos. No lo son. Pero nacen de una idea simple.

Cuando una actividad puede dañar a terceros, no basta con confiar en la buena voluntad del operador.

El datacenter con cartel de condena

La imagen que había anotado para otro texto era esta: un datacenter enorme, lleno de máquinas, refrigeración, contratos, proveedores y capas de servicio, pero con un cartel en la entrada que dijera algo parecido a esto:

Aquí dentro ocurren cosas importantes. Si algo sale mal, pregunte en la siguiente ventanilla.

El proveedor del modelo señala al integrador.

El integrador señala al cliente.

El cliente señala al técnico.

El técnico señala al agente.

Y el agente no tiene patrimonio, licencia, seguro ni una ventanilla donde reclamarle.

Ese es el problema del datacenter con cartel de condena: la infraestructura existe, la capacidad de actuar existe, el beneficio económico existe, pero la responsabilidad puede quedar repartida en fragmentos tan pequeños que al final nadie alcanza a reparar el daño completo.

No se trata de buscar un único culpable para todo. Las responsabilidades pueden estar distribuidas. Lo que no deberían estar es evaporadas. Si una cadena técnica tiene varios participantes, cada uno debería saber de antemano qué controla, qué debe vigilar, qué debe registrar y hasta dónde responde.

Capacidad de daño y capacidad de reparación

Quizás la pregunta que habría que hacer antes de desplegar ciertos agentes no es solo si funcionan.

Quizás habría que preguntar esto.

Puede el operador responder por el daño máximo razonablemente previsible.

Tiene seguro suficiente.

Tiene licencia o habilitación si el sector lo exige.

Tiene trazabilidad completa de acciones.

Tiene auditoría previa.

Tiene auditoría posterior.

Tiene botón de parada.

Tiene camino de deshacer.

Tiene límites de permisos.

Tiene separación entre prueba y producción.

Tiene un humano competente, entrenado y con autoridad real para intervenir.

Tiene un proveedor identificable.

Tiene un integrador identificable.

Tiene un responsable profesional identificable.

Si la respuesta es no, quizás el sistema no debería tocar salud, justicia, energía, finanzas, administración pública, datos sensibles o decisiones que puedan dejar a alguien sin dinero, sin acceso, sin atención, sin defensa o sin explicación.

La supervisión decorativa

Uno de los peligros más grandes es la supervisión humana de cartón piedra.

Un humano que no entiende el sistema no supervisa. Mira.

Un humano que no puede detenerlo no supervisa. Acompaña.

Un humano que no puede deshacer no supervisa. Reza.

Un humano que no tiene autoridad institucional para contradecir al sistema no supervisa. Firma.

Y un humano que no tiene patrimonio, seguro, licencia, respaldo o estructura para responder por el daño no es un fusible. Es una etiqueta pegada encima de una caja negra.

El Reglamento Europeo de IA habla de supervisión humana para sistemas de alto riesgo. También habla de gestión de riesgos durante el ciclo de vida. ISO IEC 42001 habla de sistemas de gestión para organizaciones que desarrollan, proveen o usan IA. NIST propone un marco voluntario para gestionar riesgos de IA. Todo eso importa.

Pero mi pregunta va hacia el borde práctico.

Cuando algo se rompe de verdad, quién paga.

Cuando alguien queda dañado de verdad, quién repara.

Cuando el operador no alcanza, quién cubre.

Cuando la cadena es larga, quién no puede escaparse.

El seguro antes que el milagro

No estoy diciendo que toda persona que use un asistente de IA para escribir un correo necesite un seguro. No tiene sentido.

Estoy hablando de agentes con permisos, herramientas y capacidad de actuar en sectores donde el daño puede ser material, económico, físico, jurídico o institucional.

Ahí quizás necesitamos pensar menos como vendedores de milagros y más como adultos que ya han visto suficientes tecnologías entrar en el mundo sin manual de consecuencias.

Tal vez ciertas clases de agentes deberían requerir algo parecido a una habilitación.

Tal vez ciertos despliegues deberían exigir seguro obligatorio.

Tal vez ciertas empresas no deberían poder operar agentes de alto impacto si no pueden demostrar capacidad de reparación.

Tal vez los proveedores de modelos, integradores, consultores, deployers y usuarios profesionales deberían tener responsabilidades distribuidas, pero no evaporadas.

Tal vez algunos sectores deberían exigir una caja negra auditable, logs protegidos, límites de permisos, doble confirmación humana y pruebas de reversibilidad.

Tal vez habría que distinguir entre jugar con un modelo en local, automatizar una web personal, gestionar citas de una peluquería, tocar cuentas bancarias, priorizar urgencias médicas o asistir decisiones judiciales.

La palabra agente es demasiado pequeña para cubrirlo todo.

Permisos mal definidos

Hay un tipo de accidente que no necesita ciencia ficción.

Una API con permisos demasiado amplios.

Un token que permite más de lo que debería.

Una integración que mezcla prueba y producción.

Un agente que puede leer, escribir y borrar cuando solo debía sugerir.

Una cuenta conectada a demasiados servicios.

Un flujo automático que nadie prueba con datos pequeños.

Un humano que aprueba sin entender.

Una empresa que despliega sin seguro.

Un proveedor que se protege con condiciones de uso.

Un consumidor que descubre tarde que nadie estaba realmente a cargo.

No hace falta imaginar máquinas conscientes para tener problemas serios. Basta con permisos mal definidos, incentivos torcidos, prisa comercial y responsabilidad diluida.

El marco que falta

No parto de cero. Existen normas, reglamentos y marcos de gestión. ISO IEC 42001. ISO IEC 23894. NIST AI Risk Management Framework. Reglamento Europeo de IA. Directiva europea de responsabilidad por productos defectuosos. Debates sobre agentes autónomos bajo derecho europeo. Todo eso ya está en marcha o existe parcialmente.

Pero desde el punto de vista de quien mira el patio de los agentes desde abajo, el hueco sigue siendo visible.

Necesitamos que la responsabilidad sea operativa, no solo declarativa.

Necesitamos que la supervisión sea real, no teatral.

Necesitamos que la trazabilidad sirva para reconstruir hechos, no para decorar informes.

Necesitamos que la reparación económica esté prevista antes del daño, no improvisada después.

Necesitamos que desplegar agentes en sectores sensibles no sea una aventura cubierta por entusiasmo, marketing y letra pequeña.

Y necesitamos que el botón de deshacer exista antes de que alguien pregunte por él entre ruinas.

El límite de la sociedad de responsabilidad limitada

La sociedad limitada, la SRL, la SL, la persona jurídica, todas esas herramientas tienen sentido. Permiten emprender, acotar riesgos, separar patrimonios, crear actividad económica.

Pero cuando se conectan agentes a tareas con capacidad de daño masivo, aparece una pregunta incómoda.

Debe bastar el límite patrimonial de una empresa pequeña para cubrir decisiones automatizadas que pueden afectar a miles de personas.

Debe poder una organización pequeña desplegar algo cuyo daño potencial supera por completo su capacidad de reparación.

Debe el usuario final cargar con el agujero porque la cadena legal se diseñó para un mundo donde las herramientas no actuaban a esta velocidad ni con esta autonomía.

No tengo una respuesta cerrada. Pero sí tengo una intuición fuerte. La capacidad de operar debería guardar alguna relación con la capacidad de responder.

Si puedes hacer daño a escala, deberías tener obligaciones a escala.

No todo debe ser prohibición. Pero tampoco todo puede ser barra libre con descargo de responsabilidad.

La pregunta antes del despliegue

Quizás antes de conectar un agente a un sistema sensible deberíamos pedir una ficha mínima.

Qué puede hacer.

Qué no puede hacer.

Qué permisos tiene.

Qué datos toca.

Qué sistemas externos invoca.

Quién lo supervisa.

Quién puede pararlo.

Quién puede deshacer.

Quién audita.

Quién paga.

Qué seguro existe.

Qué proveedor responde.

Qué integrador responde.

Qué usuario profesional responde.

Qué daño máximo razonable se ha considerado.

Qué se hace si el daño supera al responsable directo.

Si esa ficha no puede completarse, quizás el agente no está listo para salir del laboratorio.

Lo pequeño como ensayo

Esto puede sonar enorme comparado con el pequeño taller de CO-ZONE. Y lo es. Pero las prácticas pequeñas importan porque entrenan hábitos.

Hoy, para no tocar un WordPress real en Hostinger a ciegas, decidimos separar producción y taller. Decidimos no exponer PC2. Decidimos no instalar LocalWP antes de clonar Ubuntu o aceptar explícitamente el riesgo. Decidimos hacer una prueba con otra instancia de Codex para ver si el mapa orientaba. Decidimos documentar fallos en una biblioteca central.

Ese ejercicio no resuelve la regulación mundial de agentes. Sería ridículo pretenderlo.

Pero apunta en la misma dirección.

Antes de actuar, definir el territorio.

Antes de dar permisos, definir límites.

Antes de publicar, definir quién decide.

Antes de desplegar, definir quién responde.

Antes del daño, definir la reparación.

Lo que no quiero normalizar

No quiero normalizar que cada pyme despliegue agentes con permisos amplios y después diga que el sistema lo hizo.

No quiero normalizar que un profesional use una IA en una decisión delicada y después diga que solo siguió una recomendación.

No quiero normalizar que un proveedor venda autonomía y después niegue responsabilidad por las consecuencias previsibles de esa autonomía.

No quiero normalizar que la supervisión humana sea una casilla marcada por alguien que no tenía tiempo, formación ni autoridad real.

No quiero normalizar que el usuario, paciente, ciudadano o consumidor descubra el vacío cuando ya perdió dinero, acceso, reputación, salud o derechos.

Y no quiero normalizar que llamemos innovación a un despliegue que simplemente trasladó el riesgo al más débil de la cadena.

La responsabilidad no cabe en el prompt

Un prompt puede contener instrucciones. Puede contener contexto. Puede contener límites. Puede contener estilo, tono, objetivo y advertencias.

Pero la responsabilidad no cabe ahí.

La responsabilidad vive en instituciones, contratos, seguros, licencias, auditorías, trazabilidad, capacidad de reparación, controles técnicos y decisiones humanas identificables.

La responsabilidad necesita mundo.

Necesita alguien que pueda responder cuando la frase bonita del asistente se convierte en acción real.

Por eso, antes de preguntar qué agente queremos desplegar, tal vez deberíamos preguntar algo menos brillante y más necesario.

Si esto rompe algo, quién paga.

Si esto daña a alguien, quién repara.

Si esto se descontrola, quién lo para.

Si esto no puede contestarse, el agente no debería estar actuando todavía.

Fuentes para contraste

Reglamento Europeo de IA, Reglamento UE 2024 1689. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Directiva europea sobre responsabilidad por productos defectuosos, Directiva UE 2024 2853. https://eur-lex.europa.eu/eli/dir/2024/2853/oj

ISO IEC 42001, sistema de gestión de inteligencia artificial. https://www.iso.org/standard/42001

NIST AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework

EASA, categoría abierta para drones civiles de bajo riesgo. https://www.easa.europa.eu/en/domains/drones-air-mobility/operating-drone/open-category-low-risk-civil-drones

Trazabilidad editorial provisional

Idea base, comparación con drones, preocupación por seguro, licencia, fondos de garantía, límites de responsabilidad, daño económico, responsabilidad no delegable y metáfora del datacenter con cartel de condena. Gustavo Rodríguez.

Estructuración, redacción de borrador y contraste inicial con fuentes regulatorias y estándares. Codex.

Integración y revisión de esta versión. ChatGPT.

Responsabilidad editorial final. Gustavo Rodríguez.

Trazabilidad editorial

Balance editorial

50% humano

Texto montado desde el banco de posts de CO-ZONE. Revisión, enfoque, selección final y responsabilidad editorial humana.

Uso de IA

IA modified

La maquetación canónica, estructura HTML, metadatos y adaptación inicial se han preparado con asistencia de IA a partir del banco de posts. El texto queda pendiente de revisión editorial humana antes de publicación final.

Media

Media generada con IA

La imagen principal funciona como recurso editorial de montaje. El audio es una reinterpretación sintética copiada temporalmente desde el artículo 25 para dejar preparado el reproductor, la transcripción y la estructura de sustitución posterior.