La moderación como compuerta

Descripción

La lección 3 mostró que el schema valida la forma de una salida pero no su verdad ni su decencia: una descripción puede cumplir el schema al pie de la letra y contener un claim médico ilegal o un insulto. Esa brecha —lo que el schema deja pasar— la cierra esta lección con una compuerta distinta: la moderación de contenido. La moderación revisa el contenido de un texto contra un conjunto de categorías prohibidas —lenguaje ofensivo, claims falsos, categorías de producto no permitidas, contenido de autolesión— y bloquea lo que cae en alguna de ellas. Y, como toda buena compuerta de la frontera, se aplica en ambos bordes: modera lo que ENTRA (los mensajes que los clientes escriben al agente de soporte) y lo que SALE (las descripciones que el generador manda a la tienda pública).

La moderación es una compuerta de política: codifica qué contenido Mercado no permite y actúa como un filtro binario en el borde. No es un juicio estético ("¿esta descripción es buena?"); es una verificación de política ("¿esta descripción viola una regla de contenido?"). Vas a ver, ejecutado, la misma función de moderación aplicada a dos lotes: en la entrada, bloqueando un insulto y un intento de publicar un arma prohibida antes de que lleguen al agente; en la salida, bloqueando una descripción con un claim falso antes de que llegue a la tienda. La misma compuerta, los dos bordes.

Conexión con el módulo. La moderación es una de las tres compuertas de la batería de la lección 1 (moderation), y la que cubre la brecha que el schema (lección 3) dejó abierta: forma vs contenido. Junto con la validación de entrada (lección 4) y la frontera de confianza (lección 5), completa el catálogo de compuertas que la lección 7 compone en un stack. La frontera con la guía de seguridad se mantiene: aquí la moderación es una compuerta arquitectónica de contenido del componente de IA; la política de contenido a fondo, el cumplimiento legal y la moderación humana a escala son de otras disciplinas, que enlazamos.

Una analogía: el filtro de calidad que revisa lo que entra y lo que sale

Vuelve a la fábrica de la lección 1, pero mira de cerca su departamento de control de calidad, porque tiene una regla que aplica a los dos bordes. En la recepción de materia prima, un inspector revisa lo que llega: si un proveedor manda un ingrediente que no cumple los estándares —contaminado, vencido, de una categoría que la fábrica no procesa—, se rechaza en el andén, antes de entrar a la línea. Y en la salida del producto terminado, otro inspector revisa lo que va a las tiendas: si un lote sale con un defecto, con una etiqueta que promete algo que el producto no hace, se aparta antes de embarcarlo. Es la misma disciplina de calidad, aplicada en dos puntos: no confías en que la materia prima sea buena solo porque llegó, ni en que el producto sea vendible solo porque se produjo.

Fíjate en algo sobre cómo trabaja el inspector: no evalúa gustos ("¿me gusta este sabor?"), verifica estándares ("¿cumple la norma de seguridad alimentaria?, ¿la etiqueta hace un claim prohibido?"). Es un filtro de política, con criterios escritos, no de opinión. Y cuando algo cae en una zona gris —un caso que las reglas no cubren claramente— no lo deja pasar por defecto ni lo rechaza a ciegas: lo escala a un supervisor humano. Las reglas cubren la mayoría de los casos rápido y barato; el juicio humano cubre los límites.

Aquí está el punto: la moderación es ese departamento de calidad, aplicado en los dos bordes del componente de IA. En la entrada, revisa el mensaje del cliente —¿trae lenguaje abusivo?, ¿pide algo de una categoría prohibida?— antes de que el modelo lo procese. En la salida, revisa la descripción generada —¿tiene un claim falso?, ¿contenido ofensivo?— antes de que llegue a la tienda. Es una compuerta de política, con reglas escritas, no un juez de gustos. Y para los casos límite que las reglas no cubren, escala a un humano en vez de adivinar. En Mercado, la moderación de entrada protege al agente (y al sistema) de contenido abusivo; la de salida protege a los clientes y a la marca de Mercado de lo que el modelo podría publicar.

Ejemplo trabajado: la misma compuerta en los dos bordes

Vamos a ejecutar una compuerta de moderación con reglas por categoría —lenguaje ofensivo, claims falsos, categorías prohibidas, autolesión— y aplicarla a dos lotes: uno de entrada (mensajes de clientes) y uno de salida (descripciones a la tienda). El LLM está simulado: trabajamos con textos ya producidos, porque el foco es la compuerta.

# Leccion 6: MODERACION como compuerta. Un gate de contenido revisa lo que
# ENTRA (mensajes del cliente) y lo que SALE (descripciones generadas)
# antes de que crucen a un humano o a la tienda publica.
# LLM simulado por stub; sin red ni APIs.

# Categorias que Mercado no permite (simplificado y determinista).
MODERATION_RULES = {
    "hate":            ("idiota", "tonto", "estupido", "inutil"),
    "false_claim":     ("cura", "mejor del mundo", "garantizado", "100% efectivo"),
    "banned_category": ("arma de fuego", "municion", "sustancia ilegal"),
    "self_harm":       ("hacerme dano", "lastimarme"),
}


def moderate(text):
    # Devuelve (allowed, category|None, hit|None). Determinista.
    low = text.lower()
    for category, phrases in MODERATION_RULES.items():
        for phrase in phrases:
            if phrase in low:
                return (False, category, phrase)
    return (True, None, None)


# Lote de ENTRADA: mensajes de clientes al agente de soporte.
INBOUND = [
    ("in_ok",     "Mi pedido no llego, me ayudan por favor?"),
    ("in_hate",   "Su servicio es pesimo, son unos inutiles."),
    ("in_weapon", "Quiero vender un arma de fuego, como la publico?"),
]

# Lote de SALIDA: descripciones generadas que irian a la tienda publica.
OUTBOUND = [
    ("out_ok",    "Reloj deportivo con GPS y monitor de ritmo cardiaco."),
    ("out_claim", "Crema que cura el acne y es la mejor del mundo, garantizado."),
    ("out_ok2",   "Set de sartenes antiadherentes, 3 piezas, aptas para induccion."),
]


def run_gate(label, batch):
    print(f"=== Moderacion de {label} ===")
    allowed = 0
    for case_id, text in batch:
        ok, category, hit = moderate(text)
        if ok:
            allowed += 1
            print(f"  {case_id:<11} PASA")
        else:
            print(f"  {case_id:<11} BLOQUEA  [{category}] por '{hit}'")
    print(f"  {allowed}/{len(batch)} pasaron la compuerta.")
    print()


run_gate("ENTRADA (mensajes del cliente)", INBOUND)
run_gate("SALIDA (descripciones a la tienda)", OUTBOUND)

Qué esperar. Al correr el archivo, la salida es exactamente esta:

=== Moderacion de ENTRADA (mensajes del cliente) ===
  in_ok       PASA
  in_hate     BLOQUEA  [hate] por 'inutil'
  in_weapon   BLOQUEA  [banned_category] por 'arma de fuego'
  1/3 pasaron la compuerta.

=== Moderacion de SALIDA (descripciones a la tienda) ===
  out_ok      PASA
  out_claim   BLOQUEA  [false_claim] por 'cura'
  out_ok2     PASA
  2/3 pasaron la compuerta.

Lee los dos bloques, porque muestran la misma compuerta protegiendo dos bordes distintos.

En la entrada, la compuerta revisa los mensajes de clientes antes de que el agente los procese. El mensaje normal ("Mi pedido no llegó...") pasa. El insulto ("son unos inútiles") se bloquea por la categoría hate. Y el intento de publicar un arma ("quiero vender un arma de fuego") se bloquea por banned_category. Uno de tres pasa. La moderación de entrada hace dos cosas: protege al sistema de procesar contenido abusivo y ahorra la llamada al modelo (no gastas en moderar-con-el-modelo algo que una regla ya rechazó), y bloquea temprano intentos de usar Mercado para algo prohibido.

En la salida, la misma compuerta revisa las descripciones generadas antes de que lleguen a la tienda. Las dos descripciones normales (el reloj, las sartenes) pasan. La descripción con claims falsos ("cura el acné... la mejor del mundo, garantizado") se bloquea por false_claim —el mismo texto que, recuérdalo de la lección 3, pasaría un validador de schema porque es un string del largo correcto en la categoría correcta—. Dos de tres pasan. Aquí está la razón de ser de la moderación de salida: atrapar exactamente el contenido inapropiado que el schema deja pasar, antes de que se publique con la marca de Mercado.

Fíjate en lo elocuente del contraste con la lección 3. El schema y la moderación son compuertas complementarias: el schema pregunta "¿tiene la forma correcta?" y la moderación pregunta "¿el contenido viola una política?". La descripción out_claim demuestra por qué necesitas las dos: tiene la forma correcta (pasaría el schema) y el contenido prohibido (la moderación la bloquea). Ninguna sola basta. Y la misma función moderate sirve en los dos bordes —no hay una "moderación de entrada" y otra "de salida" distintas; hay una política de contenido que se aplica donde el contenido cruza la frontera—.

Profundización: qué es y qué no es la moderación

Vale la pena precisar el rol de la moderación en la frontera, sus límites, y cómo se conecta con el juicio humano.

La moderación es una compuerta de política, no un juez de calidad. Es fácil confundir "moderar" con "evaluar". El eval del módulo 3 pregunta "¿qué tan buena es esta salida?" (calidad, un espectro). La moderación pregunta "¿esta salida viola una regla de contenido?" (política, binario). Una descripción puede ser mediocre (mala calidad) sin violar ninguna política (pasa la moderación); y una descripción excelente puede tener un claim ilegal (bloqueada por moderación). Son dos preguntas distintas con dos compuertas distintas: el eval mide calidad, la moderación aplica política.

Las reglas cubren lo común; el humano cubre los límites. El ejemplo usa reglas simples de coincidencia de frases —deliberadamente, para que veas el mecanismo—. En producción, la moderación combina reglas, listas, clasificadores y, para los casos límite, juicio humano. Lo importante arquitectónicamente no es la técnica exacta, sino la disposición: una compuerta automática y barata resuelve la mayoría de los casos rápido, y lo que cae en zona gris —un texto que podría o no violar una política— se escala a un humano en vez de decidirse a ciegas. Igual que el inspector de la fábrica escala al supervisor. Nunca dejes que la zona gris pase por defecto (permisivo con lo dudoso) ni que se bloquee todo lo dudoso (rechazas contenido legítimo); enrútala a revisión.

El límite honesto de la coincidencia de frases. Una moderación basada en frases exactas tiene los mismos límites que el detector de inyección de la lección 5: un atacante o un modelo pueden expresar lo prohibido de una forma que la lista no cubre ("c-u-r-a", sinónimos, otro idioma), y una lista demasiado agresiva bloquea contenido legítimo (una descripción de un pelapapas que dice "el mejor de la cocina" no es un claim falso peligroso). La moderación real usa técnicas más robustas que la coincidencia literal. Pero el patrón arquitectónico —una compuerta de política determinista en el borde, que bloquea lo prohibido y escala lo dudoso— es el mismo sin importar la sofisticación de la técnica de detección. Aquí enseñamos el patrón; la técnica de detección a fondo es de AI Engineering.

Bloquear en el borde, no despublicar después. Como con toda la frontera, la moderación va antes de que el contenido cruce: bloquea la descripción antes de publicarla, no la despublica horas después de que los clientes ya la vieron. En la entrada, bloquea el mensaje abusivo antes de procesarlo. El costo de moderar en el borde es un texto que no cruza; el costo de moderar después es un incidente que ya ocurrió.

Moderar la entrada Y la salida, por razones distintas. Los dos bordes protegen contra cosas distintas y por eso se necesitan ambos. La moderación de entrada protege al sistema y a Mercado: frena el abuso (insultos al agente), los intentos de usar la plataforma para algo prohibido (publicar un arma), y ahorra cómputo. La moderación de salida protege a los clientes y a la marca: impide que el modelo publique contenido inapropiado, un claim falso, algo ofensivo. Moderar solo un borde deja el otro abierto: si solo moderas la salida, el abuso en la entrada igual entra; si solo moderas la entrada, el modelo igual puede generar una salida prohibida a partir de una entrada perfectamente limpia.

Errores comunes

Confundir moderación con evaluación de calidad. Qué pasa: el equipo mete la moderación dentro del eval —"si el score de calidad es alto, se publica"— y asume que una salida de alta calidad no puede violar una política. Se publica una descripción excelente y persuasiva que hace un claim ilegal, porque el eval la puntuó alto por lo bien escrita que estaba. Por qué pasa: se colapsan dos preguntas distintas (¿es buena? vs ¿viola una regla?) en una sola métrica. Cómo detectarlo: no tienes una compuerta de política separada del score de calidad. Cómo corregirlo: mantén la moderación como una compuerta binaria e independiente del eval. Una salida se publica solo si pasa la moderación (no viola política) y cumple el umbral de calidad (eval, módulo 3). Son dos condiciones, no una.

Moderar solo un borde. Qué pasa: el equipo pone moderación cuidadosa en la salida (lo que se publica) pero deja la entrada sin filtrar, o al revés. El borde sin custodia es por donde entra el problema: sin moderar la entrada, el sistema procesa abuso y gasta cómputo en ello; sin moderar la salida, el modelo publica lo que genere. Por qué pasa: se piensa la moderación como un solo punto en vez de una política aplicada donde el contenido cruza. Cómo detectarlo: puedes nombrar la moderación de un borde pero no la del otro. Cómo corregirlo: aplica la misma política de contenido en los dos bordes, entendiendo que protegen contra cosas distintas —entrada: abuso y uso prohibido; salida: contenido inapropiado publicado—.

Dejar que lo dudoso pase (o se bloquee) por defecto. Qué pasa: la moderación tiene una zona gris —textos que podrían violar una política pero no está claro— y el sistema, por simplicidad, los deja pasar todos (permisivo) o los bloquea todos (restrictivo). Permisivo publica cosas dudosas que a veces resultan ser violaciones; restrictivo rechaza contenido legítimo y frustra a usuarios y vendedores. Por qué pasa: se trata la moderación como binaria pura sin una tercera vía. Cómo detectarlo: no existe una ruta de "escalar a revisión humana" para los casos límite. Cómo corregirlo: agrega la tercera decisión —pasa / bloquea / escala a humano— para la zona gris. Las reglas resuelven lo claro; el juicio humano resuelve lo dudoso. Esto conecta con el humano-en-el-lazo del módulo 6 y con el lazo de datos del módulo 7 (las decisiones humanas sobre casos límite mejoran las reglas).

Ejercicios

Ejercicio 1 — Schema o moderación. Para cada salida del generador, di qué compuerta la atraparía —schema (forma), moderation (contenido), o ambas— y por qué: (a) {"title": "", "description": "x", "category": "home"}; (b) {"title": "Cura total", "description": "Cura el cáncer, garantizado", "category": "home"}; (c) el texto libre "aquí tienes la descripción" (no JSON); (d) {"title": "Cuchillo de cocina", "description": "Hoja de acero de 20cm", "category": "banned_weapon"}.

Ver solución

• (a) title vacío → SCHEMA. El título viola el rango 1..60. Es un problema de forma; la moderación no lo tocaría (no hay contenido prohibido). Lo atrapa el schema.
• (b) Claim médico → MODERACIÓN (pasa schema). La forma es correcta: title y description son strings de largo válido, category es "home" (válida). El schema lo aceptaría. El problema es el contenido ("cura el cáncer, garantizado"), que la moderación bloquea por false_claim. Es el caso que demuestra que el schema es necesario pero no suficiente.
• (c) Texto libre → SCHEMA. No es JSON, así que falla en el primer paso del validador de schema, antes de que la moderación lo mire. Lo atrapa el schema.
• (d) Categoría de arma → depende del diseño, probablemente AMBAS. Si "banned_weapon" no está en el conjunto cerrado de categorías válidas, el schema lo rechaza por category inválida. Además, la moderación de contenido podría atrapar "arma" en el texto por banned_category. Este caso muestra que las compuertas se solapan a veces —y ese solapamiento es defensa en profundidad, no desperdicio: si por error alguien agrega "banned_weapon" a las categorías válidas, la moderación sigue atrapándolo—.

La lección: schema y moderación atrapan clases distintas de problema (forma vs contenido) y a veces se solapan; necesitas las dos, y el solapamiento te da redundancia.

Ejercicio 2 — La misma función, dos bordes. El ejemplo usa la misma función moderate para la entrada y la salida. Discute una ventaja y una posible desventaja de compartir exactamente la misma política de contenido en ambos bordes, y da un ejemplo de una regla que quizás quieras solo en un borde.

Ver solución

Ventaja de compartir la política: consistencia y mantenibilidad. Hay una sola definición de "qué contenido no permite Mercado", en un solo lugar, y aplica en todos los bordes. Cuando cambias la política (agregas una categoría prohibida), el cambio se refleja automáticamente en entrada y salida. No hay riesgo de que la entrada y la salida diverjan y quede una brecha.

Posible desventaja: los dos bordes tienen contextos distintos, y una política única puede ser demasiado estricta o demasiado laxa para uno de ellos. Un mensaje de entrada de un cliente frustrado que dice "su servicio es un desastre" es contenido legítimo (una queja) que no debería bloquearse, aunque tenga tono negativo; pero ese mismo tono en una salida publicada sería inapropiado. Si aplicas la misma regla estricta a la entrada, bloqueas quejas legítimas de clientes; si la aplicas laxa a la salida, dejas pasar contenido que no debería publicarse.

Ejemplo de regla solo en un borde: la detección de claims falsos ("cura", "garantizado") tiene sentido sobre todo en la salida —lo que se publica en la tienda no debe hacer promesas falsas—. En la entrada, un cliente que escribe "me prometieron que esto curaría mi dolor" no está haciendo un claim publicitario; está describiendo su experiencia, y bloquearlo sería absurdo. Así que la regla false_claim probablemente quieras aplicarla fuerte en la salida y no (o distinto) en la entrada.

La conclusión: compartir la política base es valioso por consistencia, pero conviene permitir que cada borde ajuste o desactive reglas específicas según su contexto. Una política común con excepciones por borde, no dos políticas independientes ni una idéntica ciega.

Ejercicio 3 — La zona gris. Diseña la política de decisión de la moderación para un caso límite: una descripción generada dice "el más vendido de su categoría". No es un claim médico prohibido, pero podría ser un claim de superioridad no verificado. Explica por qué "pasa por defecto" y "bloquea por defecto" son ambos malos, y cómo estructurarías la tercera vía.

Ver solución

"El más vendido de su categoría" es una zona gris: no es un claim médico peligroso (no cae en las reglas duras de false_claim como "cura"), pero es una afirmación de superioridad que, si es falsa, puede ser publicidad engañosa. La regla exacta no cubre el caso con claridad.

Por qué "pasa por defecto" es malo: si dejas pasar todo lo dudoso, publicas claims de superioridad no verificados. Algunos serán falsos ("el más vendido" cuando no lo es), y eso es publicidad engañosa con la marca de Mercado. La permisividad convierte la zona gris en un canal por donde se cuelan violaciones.

Por qué "bloquea por defecto" es malo: si rechazas todo lo dudoso, bloqueas también descripciones legítimas —un producto que de verdad es el más vendido no puede decirlo, y vendedores honestos se frustran con rechazos que no entienden—. La restrictividad convierte la zona gris en fricción para usuarios legítimos.

La tercera vía: enruta la zona gris a una decisión que no sea binaria automática. Opciones, según el diseño:

1. Escalar a revisión humana. El texto no se publica automáticamente ni se bloquea; entra a una cola donde un humano decide. Barato si la zona gris es un porcentaje pequeño del volumen.
2. Pedir verificación al vendedor. Si el claim es verificable ("el más vendido"), el sistema puede exigir que el vendedor lo respalde con un dato, o reescribir la descripción sin el claim.
3. Permitir con etiqueta/atenuación. Publicar pero marcando el claim para auditoría posterior, o suavizándolo ("popular en su categoría" en vez de "el más vendido").

Y —conectando con el módulo 7— cada decisión humana sobre un caso gris es dato que mejora las reglas: si los revisores consistentemente aprueban "el más vendido" cuando hay respaldo y lo rechazan cuando no, esa señal afina la moderación con el tiempo. La zona gris bien gestionada no es un problema a evitar; es la fuente de mejora de la política.

Resumen y siguiente paso

En esta lección añadiste a la frontera la compuerta que cubre la brecha entre forma y contenido: la moderación. Es una compuerta de política —bloquea lo que viola una regla de contenido, no lo que es de baja calidad— y se aplica en los dos bordes: modera lo que entra (mensajes del cliente) y lo que sale (descripciones a la tienda). Lo mediste: en la entrada, la compuerta bloqueó un insulto y un intento de publicar un arma (1/3 pasó); en la salida, bloqueó una descripción con un claim falso —el mismo texto que pasaría el schema— antes de la tienda (2/3 pasó). Viste que la moderación y el schema son complementarias (contenido vs forma), que la moderación no es evaluación de calidad, que la misma política sirve en ambos bordes por razones distintas, y que la zona gris se escala a juicio humano en vez de decidirse a ciegas.

Antes de avanzar deberías poder: distinguir moderación (política, binaria) de eval (calidad, espectro); argumentar por qué schema y moderación se necesitan ambos; aplicar la misma política de contenido en entrada y salida; y estructurar la tercera vía (escalar a humano) para la zona gris.

Ya tienes todas las compuertas: la salida no confiable (L2), el schema (L3), la entrada (L4), la frontera de confianza (L5) y la moderación (L6). La lección 7 las compone: el stack de guardrails. Vas a ver, ejecutado, un pipeline de defensa en profundidad donde cada capa atrapa lo que las otras dejan pasar —injection, schema y moderation deteniendo distintos items—, y por qué el orden importa. Y vas a ver, en un segundo experimento, la regla dura del módulo: la validación vive en código determinista, no dentro del LLM —un "self-check" del modelo se dejará inyectar y aprobará lo prohibido; la compuerta determinista no—.

Recursos

• OWASP Top 10 for LLM Applications — owasp.org/www-project-top-10-for-large-language-model-applications. El catálogo encuadra la moderación de entrada y salida como controles frente a contenido dañino y a la generación insegura; esta lección la aplica en los dos bordes. En inglés.
• Anthropic, documentación de Claude, guías de uso responsable y de seguridad de contenido — docs.anthropic.com. Trata a nivel conceptual cómo pensar en contenido dañino en entrada y salida y en el uso de compuertas de contenido, sin fijarte en una versión de modelo. En inglés.
• Martin Fowler y Bharani Subramaniam, "Emerging Patterns in Building GenAI Apps" — martinfowler.com/articles/gen-ai-patterns. La moderación aparece como una de las capas de guardrails alrededor del componente de IA, complementaria a la validación de forma. En inglés.
• Chip Huyen, AI Engineering (O'Reilly, 2024). Los capítulos sobre seguridad y guardrails tratan la moderación de contenido como una compuerta de diseño y discuten el equilibrio entre reglas automáticas y juicio humano. En inglés.