Construimos brand compliance como código — y tú deberías hacer lo mismo

En algún cajón de tu organización hay un PDF de brand guidelines. Dice que nunca uses la palabra "agencia", que tu tono es "cercano pero profesional", que los CTAs cierran con punto y no con exclamación. Nadie lo lee. El nuevo redactor publica "nuestra agencia ofrece sinergias disruptivas" y nadie lo pilla hasta que el post lleva tres días en LinkedIn.

Multiplica este problema por mil cuando los redactores son IA. La velocidad a la que generan contenido es exactamente la velocidad a la que pueden romper tu marca. Un PDF no escala. Lo que sí escala es compliance como código.

BRAND.md: la marca en formato máquina

Lo primero es trasladar la guía de marca a un formato que las máquinas entiendan sin ambigüedad. En Agentikas es un fichero markdown con secciones específicas:

## Terminology

### Use (preferred terms)
- "laboratorio" / "lab"
- "ingenieros" / "engineers"
- "WebMCP"
- "open source"

### Avoid (banned terms)
- "agencia" / "agency"
- "consultora" / "consultancy"
- "transformación digital" / "digital transformation"
- "sinergia" / "synergy"
- "disruptivo" / "disruptive"
- "revolucionario" / "revolutionary"

El formato es plano por una razón: el autor de marca no necesita saber programar. Edita el markdown, hace commit, los siguientes posts se validan contra la nueva regla. Sin deploy, sin coordinación, sin ticket.

El revisor: regex con conciencia de plurales y géneros

El primer instinto fue obvio: pasarle el post a un segundo modelo y pedirle "valida que sigue la guía de marca". Funcionaba en el 80% de los casos. El otro 20% se rompía de formas creativas — el modelo "olvidaba" un término prohibido, o lo "permitía" porque le pareció bien en contexto. Y costaba un dólar cada cien posts.

La alternativa que terminamos usando es determinista: regex con conciencia lingüística. Una librería de ~200 líneas de TypeScript que hace tres cosas:

1. Lee la lista de términos prohibidos del BRAND.md del blog.
2. Para cada término, genera variantes morfológicas — plurales (agencia → agencias), femenino/masculino (consultor → consultora), formas derivadas (disruptivo → disruptivos, disruptiva).
3. Recorre el HTML del post evitando contenido dentro de <code> o <pre> (un post sobre Cloudflare puede mencionar "consultancy" en un ejemplo de código sin que rompa nada).

El output es estructurado:

{
  "score": 78,
  "violations": [
    {
      "term": "agencia",
      "found_as": "agencias",
      "context": "...nuestras agencias asociadas...",
      "suggestion": "laboratorios"
    }
  ],
  "warnings": [
    { "type": "tone", "issue": "Sentence too corporate", "snippet": "..." }
  ],
  "passed": false
}

Tres campos importan en práctica: el score (0-100), las violaciones con contexto exacto, y las sustituciones sugeridas. Threshold para publicar automáticamente: 90. Entre 70 y 89, el editor lo muestra al autor con highlights. Por debajo, vuelta a generar.

El detalle que importa: variantes morfológicas

El primer prototipo solo matcheaba el término exacto. Prohibías "agencia" y el revisor pasaba por alto "agencias", "agencial", "Agencia". Cero protección práctica.

La capa de variantes es lo que convierte la regla en una regla. Para español, generamos:

• Singular y plural (agencia / agencias)
• Mayúsculas y minúsculas insensible
• Géneros si el término es adjetivo (disruptivo / disruptiva / disruptivos / disruptivas)
• Familias derivadas declaradas explícitamente (sinergia → sinérgico, sinérgica)

Para inglés, similar pero más simple — pluralización regular cubre el 90%, y declaras irregulares cuando aparecen.

No es perfecto. No reemplaza un linter de tono basado en LLM. Pero captura el 95% de las infracciones reales, en menos de 100ms, gratis.

Por qué determinista, no LLM

Hay un argumento razonable para usar un LLM para validar: detecta nuance, capta tono, "entiende" contexto. Todo cierto. Pero hay tres razones por las que el regex gana en el caso de marca:

1. Velocidad. 100ms vs. 2 segundos. En un editor en vivo donde el autor reescribe y revalida diez veces por minuto, la diferencia es noche y día.
2. Predictibilidad. La misma input produce el mismo output, siempre. Cuando un LLM aprueba un post hoy y rechaza el mismo post mañana, pierdes la confianza del autor instantáneamente.
3. Coste cero. Cada generación pasa por el revisor. Si cada revisión cuesta tokens, multiplicas el coste de la plataforma. Si cuesta CPU local, el coste marginal es indistinguible de cero.

El LLM tiene su sitio — para revisar tono, sugerir reescrituras, captar problemas semánticos. Pero como gate de publicación, lo determinista gana. La regla la escribes una vez, la enforce mil millones de veces sin variación.

El paso siguiente: revisor LLM como segundo nivel

Hoy el revisor determinista es la capa de defensa primaria. Hay un segundo nivel, opcional y configurable por blog: un LLM con un reviewer_role custom (definible por el autor) que hace una pasada de tono. No bloquea la publicación — sugiere mejoras. Es el equivalente al "lo leyó alguien antes de pulsar publicar" sin necesidad de que ese alguien exista.

Esa segunda capa todavía no está en producción. El primer nivel — regex determinista — sí, y captura suficiente como para que ningún post haya salido a LinkedIn con "sinergia" desde que existe.

---

El revisor de marca y la plantilla de BRAND.md están en github.com/agentikas/agentikas-skills con licencia MIT. Forka, edita la lista, mete tu propia marca. Y si encuentras una variante morfológica que se nos escapó, abre un PR.