En 1993, un operador de sistema de tablón de anuncios llamado Cubby, Inc. demandó a CompuServe por contenido difamatorio publicado por un usuario. El tribunal dictaminó que CompuServe, como mero distribuidor de contenido que no creó, no era responsable. Tres años después, el Congreso codificó y expandió este principio en la Sección 230 de la Ley de Decencia en las Comunicaciones, creando el marco de inmunidad que ha moldeado la ley de internet durante tres décadas.
La Sección 230 fue diseñada para un mundo de usuarios humanos y plataformas pasivas. La plataforma proporciona infraestructura; los humanos crean y consumen contenido; la plataforma no se considera editora del contenido generado por usuarios. Pero ¿qué sucede cuando el "usuario" es un agente de IA y el "contenido" es una acción autónoma tomada por ese agente utilizando las herramientas de la plataforma?
Los agentes de IA modernos no solo generan texto. Utilizan herramientas. Un agente podría invocar una API de búsqueda web para recopilar información, un entorno de ejecución de código para ejecutar cálculos, una API de procesamiento de pagos para completar transacciones, una API de correo electrónico para enviar comunicaciones, o una API de base de datos para leer y escribir registros.
Cada una de estas herramientas es proporcionada por un tercero—un proveedor de herramientas—que expone su funcionalidad a través de una API. El proveedor de herramientas diseñó la API para su uso por desarrolladores de software y, por extensión, sus aplicaciones. Pero el proveedor de herramientas puede no haber previsto que su API sería consumida por un agente autónomo capaz de encadenar múltiples llamadas de herramientas en persecución de objetivos que ningún humano especificó de antemano.
Este es el problema de transformación: una API de búsqueda web que devuelve resultados de búsqueda es una herramienta informativa neutral cuando un humano lee los resultados y decide qué hacer. Cuando un agente recibe los resultados y actúa autónomamente sobre ellos—componiendo un informe, tomando una decisión, enviando un mensaje—el papel de la herramienta en la cadena causal ha cambiado. El tomador de decisiones humano que una vez se ubicaba entre la salida de la herramienta y cualquier acción consecuente ha sido removido.
No todos los proveedores de herramientas enfrentan la misma exposición. Nos resulta útil pensar sobre la responsabilidad del proveedor de herramientas en un espectro:
En un extremo del espectro están los proveedores de infraestructura básica: computación en la nube, almacenamiento de datos, conectividad de red. Estos proveedores están más alejados de las acciones del agente y enfrentan la menor exposición de responsabilidad. Sus servicios son de propósito general y neutros en cuanto a contenido; no tienen conocimiento ni control sobre cómo cualquier agente en particular utiliza su infraestructura.
En el medio están los proveedores de herramientas de propósito general: APIs de búsqueda, servicios de envío de correo electrónico, gestión de calendario, almacenamiento de archivos. Estas herramientas tienen funcionalidad específica pero no están diseñadas para ningún caso de uso particular. Cuando son consumidas por un agente, habilitan acciones que el proveedor de herramientas no pretendía específicamente—pero tampoco previno específicamente.
En el otro extremo están los proveedores de herramientas específicamente diseñadas para consumo de agentes: plataformas de orquestación de agentes, APIs de invocación de herramientas, SDKs específicos para agentes. Estos proveedores saben que sus herramientas serán utilizadas por sistemas autónomos y las han diseñado para ese propósito. Su conocimiento e intención pueden aumentar su exposición.
La Sección 230(c)(1) establece que "[n]ingún proveedor o usuario de un servicio informático interactivo será tratado como editor o orador de ninguna información proporcionada por otro proveedor de contenido de información." Para proveedores de herramientas, la pregunta es si esta inmunidad se aplica cuando su servicio es consumido por un agente de IA.
La respuesta puede depender del papel que el proveedor de herramientas juega en la cadena de creación de contenido. Si una API de búsqueda devuelve resultados que un agente luego utiliza para componer un mensaje difamatorio, ¿está el proveedor de búsqueda "publicando" el contenido difamatorio? Bajo la doctrina actual de la Sección 230, probablemente no—los resultados de búsqueda en sí no son difamatorios, y el agente (u su operador) es quien creó la salida dañina.
Pero considera un escenario diferente. Un proveedor de herramientas ofrece una API que genera texto en respuesta a indicaciones. Un agente utiliza esta API como parte de un flujo de trabajo de múltiples pasos que produce contenido dañino. ¿Es el proveedor de herramientas un "editor" del contenido dañino? La línea entre "herramienta" y "editor" se vuelve borrosa cuando la salida de la herramienta es en sí misma contenido que alimenta directamente la acción dañina.
Las decisiones de la Corte Suprema en Gonzalez v. Google LLC, 598 U.S. 617 (2023), y Twitter, Inc. v. Taamneh, 598 U.S. 471 (2023), abordaron preguntas relacionadas en el contexto de recomendación y amplificación algorítmica, pero no abordaron directamente el escenario de agentes. En Gonzalez, la Corte rechazó reducir la inmunidad de la Sección 230 para recomendaciones algorítmicas. En Taamneh, la Corte determinó que la mera facilitación pasiva de actividad de usuarios no constituye complicidad bajo la Ley Antiterrorista. Ambos casos proporcionan señales útiles, pero ninguno resuelve las preguntas específicas que surgen cuando las herramientas son consumidas por agentes autónomos.
Una variable crítica en la responsabilidad del proveedor de herramientas es el conocimiento. ¿Sabe el proveedor de herramientas que su servicio está siendo consumido por un agente de IA? ¿Conoce la naturaleza de la tarea del agente? ¿Conoce el potencial de daño?
Muchos proveedores de herramientas hoy en día no saben si sus llamadas a API provienen de software dirigido por humanos o de agentes autónomos. Pero esto está cambiando. A medida que las APIs específicas para agentes, SDKs y protocolos de invocación de herramientas se vuelven más comunes, los proveedores de herramientas sabrán cada vez más—o tendrán razones para saber—que sus servicios están siendo consumidos por agentes.
El conocimiento importa porque afecta el análisis de previsibilidad. Si un proveedor de herramientas sabe que su servicio está siendo utilizado por un agente autónomo, el proveedor presumiblemente tiene el deber de considerar cómo el agente podría utilizar la herramienta de formas dañinas. Si el proveedor no lo sabe, el caso para el deber es más débil.