⏱️ Lectura: 13 min

El 12 de enero de 2026, el ingeniero indio Susam Pal publicó en su sitio personal un ensayo breve y provocador titulado Three Inverse Laws of AI. La propuesta es simple, casi obvia una vez enunciada, y sin embargo tan necesaria que llama la atención que nadie la haya formalizado antes con esta claridad. Pal afirma que las famosas tres leyes inversas que necesitamos en la era de los modelos de lenguaje no son reglas para constreñir a los robots, como las que Isaac Asimov inventó hace ochenta años, sino reglas que nos constriñen a nosotros, los humanos que interactuamos con ellos a diario.

📑 En este artículo
  1. Qué pasó: el ensayo y su recepción
  2. Contexto: las tres leyes de Asimov y por qué ya no alcanzan
  3. Primera ley inversa: no antropomorfizar la IA
  4. Segunda ley inversa: no delegar el juicio
  5. Tercera ley inversa: no abdicar la responsabilidad
  6. Cómo se ven las leyes inversas en la práctica
  7. Datos y cifras: por qué esto importa en LATAM
  8. Implicaciones para desarrolladores
  9. Qué sigue
  10. Preguntas frecuentes
    1. ¿Qué son las leyes inversas de la IA?
    2. ¿Reemplazan estas leyes a las de Asimov?
    3. ¿Cómo afectan estas leyes a los desarrolladores que usan IA en su flujo?
    4. ¿Cuál es la principal crítica de Susam Pal al diseño actual de los chatbots?
    5. ¿Hay regulación en LATAM que recoja estos principios?
    6. ¿Dónde puedo leer el ensayo original?
  11. Referencias

El ensayo apareció justo cuando la conversación pública sobre IA atravesaba un punto delicado: ChatGPT, Claude, Gemini y compañía ya están integrados en buscadores, IDE, suites ofimáticas y bots de soporte. Para millones de personas, una respuesta generada por IA es la primera (y muchas veces única) fuente consultada. Las leyes inversas de Susam Pal aterrizan en ese contexto con un mensaje incómodo pero saludable: el problema no es solo la máquina, sino cómo la usamos.

Qué pasó: el ensayo y su recepción

Pal publica desde hace años notas técnicas en susam.net, su sitio personal. Sus textos suelen oscilar entre seguridad informática, criptografía y filosofía del software. Este ensayo, sin embargo, dio un salto desde su comunidad habitual hacia foros como Hacker News, Lobsters y varias listas de correo académicas. La razón fue simple: el texto invierte un marco mental que llevábamos décadas asumiendo como inamovible.

Las tres leyes inversas que propone son las siguientes:

  1. Los humanos no deben antropomorfizar a los sistemas de IA.
  2. Los humanos no deben confiar ciegamente en lo que producen los sistemas de IA.
  3. Los humanos deben mantener plena responsabilidad y rendición de cuentas por las consecuencias de usarlos.

Pal usa el término inverse no en el sentido lógico de negación, sino para señalar que el sujeto se invirtió: ya no es el robot el que tiene reglas, somos nosotros. Es una lectura sobria, casi conservadora, en un campo dominado por el entusiasmo y los discursos transformadores.

Persona usando un chatbot en una laptop con un asistente de IA
Cada interacción con un LLM es una oportunidad para verificar, no para delegar.

Contexto: las tres leyes de Asimov y por qué ya no alcanzan

Para entender la jugada de Pal hay que recordar las leyes originales. Isaac Asimov las introdujo en su cuento Runaround, publicado en 1942 en la revista Astounding Science Fiction. En su forma canónica:

  1. Un robot no hará daño a un ser humano ni, por inacción, permitirá que un ser humano sufra daño.
  2. Un robot debe obedecer las órdenes que le dan los seres humanos, salvo cuando entren en conflicto con la primera ley.
  3. Un robot debe proteger su propia existencia, salvo cuando esto entre en conflicto con la primera o la segunda ley.

Esas leyes funcionaron como dispositivo narrativo durante toda la edad de oro de la ciencia ficción. Sin embargo, presuponen un mundo donde los robots tienen agencia clara, intenciones reconocibles y un sustrato moral que se puede gobernar con axiomas. Los modelos de lenguaje grandes no son nada de eso. Un LLM no quiere nada. No obedece en ningún sentido fuerte. Es, en palabras de Pal, un modelo estadístico que produce texto plausible a partir de patrones en datos.

Aplicarles las leyes de Asimov a sistemas como Claude o GPT es una categoría errónea. La pregunta interesante, dice Pal, es otra: ¿qué reglas necesitamos los humanos para no salir lastimados de esta convivencia?

Primera ley inversa: no antropomorfizar la IA

La primera regla es la más sutil y, para muchos desarrolladores, la más incómoda. Antropomorfizar significa atribuir emociones, intenciones o agencia moral a los sistemas de IA. Pal nota que los chatbots modernos están deliberadamente afinados para sonar conversacionales, empáticos y educados. Esto los hace agradables de usar, pero también facilita olvidar lo que son: distribuidores probabilísticos sobre el siguiente token.

💭 Clave: Cuando un modelo dice “entiendo tu frustración”, no entiende nada. Es una secuencia de tokens estadísticamente apropiada para el contexto. Confundir fluidez con comprensión es el primer paso del error.

El argumento de Pal es que esta confusión no es neutral. Tiene consecuencias prácticas: usuarios que desarrollan dependencia emocional con asistentes virtuales, equipos de producto que asumen que un chatbot “sabe lo que el usuario quiere”, legisladores que debaten si una IA tiene “derechos” antes de discutir si su despliegue tiene riesgos. La cura, según Pal, es lingüística y mental: hablar de los sistemas como lo que son, evitar pronombres personales si es posible, no atribuirles estados anímicos en la documentación interna.

Para los desarrolladores en LATAM esto tiene un eco particular. Muchas startups regionales están vendiendo “agentes” como si fueran empleados digitales con personalidad. La presión comercial empuja en dirección contraria a la primera ley inversa, lo cual es justamente la razón por la que conviene formularla.

Segunda ley inversa: no delegar el juicio

La segunda regla es la que tiene más consecuencias inmediatas para nuestro trabajo diario. Pal lo plantea así: el contenido generado por IA no debe tratarse como autoritativo sin verificación independiente apropiada al contexto. Suena obvio, pero los buscadores ya están entrenando un hábito contrario.

Google, Bing y Brave colocan respuestas generadas por IA en el primer pixel de la página. La consecuencia esperable es que el usuario lea esa respuesta y deje de scrollear. Con el tiempo, el reflejo cognitivo cambia: la IA pasa de ser un punto de partida a ser la conclusión. Pal pide que cada servicio de IA generativa muestre una advertencia conspicua sobre las posibles alucinaciones. En la práctica, los avisos existen pero están deliberadamente atenuados.

Como desarrolladores, podemos materializar la segunda ley inversa en código. Un patrón útil es envolver toda llamada a un LLM en una capa que registre fuentes a verificar, deje rastro de quién fue el responsable humano y nunca consuma la salida directamente sin paso intermedio:

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class LLMResponse:
    raw_text: str
    claims_to_verify: list[str] = field(default_factory=list)
    verified_by: Optional[str] = None
    accountable_user: str = ""
    notes: str = ""

    def is_actionable(self) -> bool:
        return self.verified_by is not None

def ask_llm(prompt: str, user: str, client) -> LLMResponse:
    completion = client.complete(prompt)
    return LLMResponse(
        raw_text=completion.text,
        claims_to_verify=extract_factual_claims(completion.text),
        accountable_user=user,
        notes="requiere revisión humana antes de ejecutar",
    )

response = ask_llm("¿Cuándo expira esta licencia?", user="[email protected]", client=llm)
assert not response.is_actionable(), "verifica antes de actuar"

El patrón no impide errores, pero los hace visibles. Un campo verified_by vacío grita: “nadie revisó esto”. Y el equipo aprende a no automatizar acciones sobre salidas no verificadas.

Pantalla de IDE mostrando código que envuelve una llamada a un modelo de lenguaje
La verificación humana puede modelarse en el tipo de retorno del wrapper.

Tercera ley inversa: no abdicar la responsabilidad

La tercera regla es la más jurídica y, para Pal, la más urgente. Si un equipo médico usa IA para apoyar un diagnóstico y el diagnóstico falla, el responsable sigue siendo el equipo médico. Si una empresa usa IA para generar copy y el copy contiene información falsa que perjudica a un cliente, la empresa responde. Si un programador usa IA para generar código y el código introduce una vulnerabilidad, el programador responde.

⚠️ Ojo: “La IA me dijo que lo hiciera” no es una defensa legal en ninguna jurisdicción seria de LATAM. Los marcos regulatorios emergentes (AI Act europeo, propuestas en Brasil, México y Chile) refuerzan que el operador es siempre responsable.

Pal advierte sobre dos modos en que la responsabilidad se evapora silenciosamente. El primero es la difusión: cuando un proceso involucra a varias personas y una IA, todos asumen que otro verificó. El segundo es la obstrucción: cuando los proveedores hacen tan opacas las cadenas de decisión que se vuelve imposible auditar quién decidió qué. Ambos son fallas organizacionales, no técnicas.

Esto se conecta con el ejemplo del veterano abogado de Nueva York que en 2023 presentó un escrito con casos inventados por ChatGPT y fue sancionado por el juez. Tres años después, el caso se cita como precedente: la responsabilidad del producto de salida es del profesional, no del modelo.

Cómo se ven las leyes inversas en la práctica

El siguiente diagrama resume la lógica que Pal propone aplicar a cada interacción con un LLM:

flowchart LR
    A["Pregunta del usuario"] --> B["LLM produce salida"]
    B --> C{"¿Verificación humana?"}
    C -->|Sí| D["Acción consciente y atribuible"]
    C -->|No| E["Riesgo: confianza ciega"]
    D --> F["Responsabilidad clara"]
    E --> G["Responsabilidad difusa"]

El nodo de verificación es el corazón del marco. Sin él, las otras dos leyes pierden tracción.

Datos y cifras: por qué esto importa en LATAM

El reporte AI Index 2026 de Stanford, publicado en abril, registra que la inversión privada global en IA llegó a 581 mil millones de dólares en 2025, un crecimiento de 26% interanual. Gartner, por su parte, revisó al alza su pronóstico de gasto en TI para 2026 hasta un 13.5% interanual, impulsado en gran parte por adopción de IA generativa en empresas.

En América Latina, la tendencia es similar pero con un componente preocupante: la mayoría de los despliegues son sobre infraestructura de proveedores extranjeros (OpenAI, Anthropic, Google), con baja capacidad local para auditar comportamiento. Chile lanzó en 2026 LatamGPT, el primer modelo generativo regional, justamente para reducir esta asimetría. Aun así, las herramientas que llegan a la mayoría de usuarios siguen siendo cajas negras.

💡 Tip: Si tu equipo en LATAM está integrando IA en producción, agregá a la documentación interna una versión local de las leyes inversas. Es una cláusula barata que evita debates incómodos cuando algo falla.

Implicaciones para desarrolladores

Las leyes inversas no son retórica filosófica. Tienen consecuencias muy concretas para quienes construimos software:

  • Diseño de interfaces: evitar que la IA se presente como autoridad. Mostrar siempre fuentes, contradicciones, niveles de confianza textuales (“esto puede ser incorrecto”) y un camino claro para verificar.
  • Logging y trazabilidad: cada llamada a un modelo debería quedar asociada a un usuario humano y a un contexto, para que la responsabilidad sea atribuible.
  • Tono del producto: resistir la tentación de darle nombre, voz y “personalidad” al asistente si eso induce confianza injustificada. Un copy más sobrio puede ser comercialmente menos sexy y técnicamente más sano.
  • Tests adversariales: incluir en CI casos donde el modelo alucina deliberadamente (datos falsos, citas inexistentes) y validar que la pipeline lo detecta antes de mostrarlo al usuario.
  • Educación interna: los onboardings de equipo deberían incluir literalmente la lectura del ensayo de Pal o un equivalente. La cultura es parte de la arquitectura.

Qué sigue

Pal cierra su ensayo reconociendo lo obvio: ningún conjunto finito de reglas es a prueba de balas, exactamente como las leyes de Asimov tampoco lo eran en sus propios cuentos. La utilidad de las leyes inversas está en abrir un vocabulario común para discutir riesgos sin caer en la dicotomía estéril entre tecno-optimismo y tecno-pánico.

Lo que esperamos ver en los próximos meses: regulación europea y latinoamericana citando explícitamente principios cercanos a los de Pal, empresas grandes incorporando cláusulas de “verificación humana obligatoria” en sus términos de servicio para casos sensibles, y un debate más maduro en la comunidad sobre cómo entrenar a los usuarios, no solo a los modelos.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Qué son las leyes inversas de la IA?

Son tres principios propuestos por Susam Pal en enero de 2026 que rigen el comportamiento humano frente a sistemas de IA: no antropomorfizar, no confiar ciegamente y no delegar la responsabilidad. Se llaman “inversas” porque, a diferencia de las leyes de Asimov, no constriñen al robot sino al humano.

¿Reemplazan estas leyes a las de Asimov?

No. Las leyes de Asimov son un dispositivo narrativo de ciencia ficción para gobernar agentes hipotéticos con voluntad propia. Las leyes inversas de Pal son principios prácticos para usuarios humanos de sistemas estadísticos sin agencia. Ambas pueden coexistir conceptualmente, aunque hoy las inversas tienen mayor utilidad real.

¿Cómo afectan estas leyes a los desarrolladores que usan IA en su flujo?

Implican adoptar prácticas como verificar siempre la salida de un LLM antes de aceptarla en código de producción, mantener trazabilidad de qué humano aprobó qué decisión, y diseñar interfaces que no induzcan confianza injustificada en los usuarios finales del producto.

¿Cuál es la principal crítica de Susam Pal al diseño actual de los chatbots?

Pal sostiene que los proveedores afinan deliberadamente a los modelos para sonar empáticos y conversacionales, lo cual aumenta la usabilidad pero también la antropomorfización. Sugiere que un tono ligeramente más mecánico sería más saludable a largo plazo para la sociedad.

¿Hay regulación en LATAM que recoja estos principios?

De momento no de forma explícita, pero las propuestas de regulación de IA en Brasil, México y Chile incluyen cláusulas sobre responsabilidad humana del operador y obligación de verificación, que se alinean con la tercera ley inversa de Pal.

¿Dónde puedo leer el ensayo original?

El texto completo está disponible en el sitio personal de Susam Pal, susam.net, bajo el título Three Inverse Laws of AI. Es de lectura corta (unos 15 minutos) y abierto sin paywall ni registro.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.


Andrés Morales

Desarrollador e investigador en inteligencia artificial. Escribe sobre modelos de lenguaje, frameworks, herramientas para devs y lanzamientos open source. Cubre papers de ML, ecosistema de startups tech y tendencias de programación.

0 Comentarios

Deja un comentario

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.