Si dos copilotos responden distinto sobre el mismo producto, la próxima inversión no debería ser otra licencia. Implemente una capa de conocimiento de marketing: hechos, claims, ofertas, evidencias, reglas de canal y aprendizajes gobernados, cada uno con fuente, responsable, mercado, vigencia y uso permitido. Después conecte un solo flujo valioso —por ejemplo, brief y producción de campañas— y mida si el equipo llega antes a una salida aprobada, con menos correcciones factuales.
La capa no es una carpeta compartida, un chatbot sobre PDFs ni otro DAM. Separa autoridad de material de trabajo, resuelve versiones en conflicto, restringe recuperación por país y fecha, muestra la fuente utilizada y crea un camino de corrección. RAG puede localizar contexto; no decide qué claim está aprobado, quién responde por él ni cuándo vence.
Por qué otra herramienta puede aumentar el retrabajo
El conocimiento suele quedar repartido entre presentaciones de marca, fichas de producto, materiales comerciales, notas legales, espacios de campaña, CMS, CRM, PIM, DAM y conversaciones con agencias. Un copiloto recupera un precio antiguo; otro resume un posicionamiento reemplazado; un equipo regional adapta un claim aprobado solo para otro país. El modelo parece inconsistente porque el sistema de conocimiento es inconsistente.
La falla aparece al final como copy incorrecto o aprobación lenta, pero nace antes: no hay jerarquía de fuentes, responsable del dato, fecha efectiva ni regla de mercado. Pedir al modelo que use información correcta no crea esos controles. Una implementación útil convierte el conocimiento en parte de la operación, no en otro archivo adjunto al prompt.
Contrato de Conocimiento de Marketing: nueve campos
- Unidad — un hecho, claim, oferta, prueba, regla o decisión reutilizable con contexto suficiente.
- Fuente de autoridad — sistema, documento o especialista responsable que lo confirma.
- Responsable — quién responde por la vigencia y aprueba cambios.
- Mercado e idioma — dónde puede usarse y qué versión es primaria.
- Vigencia — fecha de inicio, expiración o evento que obliga a revisar.
- Evidencia — investigación, política, especificación, contrato o dato que sustenta la afirmación.
- Uso permitido — canales, públicos, formatos, límites y prohibiciones explícitas.
- Dependencias — producto, precio, disponibilidad, derechos, consentimiento o aprobación legal.
- Rastro — versión, derivación, activos publicados que lo usaron y ruta de corrección.
El contrato puede comenzar como un schema compacto sobre las fuentes actuales. No exige migrar todo el contenido corporativo ni comprar una plataforma. PROV-O de W3C ofrece un modelo de referencia para representar entidades, actividades, agentes y derivaciones entre sistemas. El proyecto puede adoptar los conceptos de procedencia sin implementar toda la ontología.
Elija un flujo, no toda la biblioteca corporativa
Empiece con una familia recurrente de campaña, un producto y un país. Liste las preguntas que generan más idas y vueltas: qué beneficio se puede prometer, qué evidencia lo respalda, qué oferta está vigente, qué aclaración es obligatoria y qué adaptación local está permitida. Un recorte acotado revela conflictos reales, prueba responsables y demuestra integración antes de escalar.
Para datos estructurados y deterministas —precio actual, disponibilidad, elegibilidad o fecha— prefiera API, regla o sistema transaccional. Use recuperación semántica para material no estructurado, como guía de marca, investigación, playbooks y respaldo de claims. Use generación para sintetizar o adaptar dentro de los límites recuperados. Llevar todo a una base vectorial convierte respuestas exactas en aproximaciones innecesarias.
El recorrido desde la fuente hasta la salida aprobada
- 1. Inventariar — mapear fuentes, versiones, permisos, responsables y conflictos del flujo elegido.
- 2. Resolver autoridad — definir qué fuente prevalece, quién decide excepciones y cuándo revisar.
- 3. Estructurar — crear unidades del contrato conservando el documento original y su procedencia.
- 4. Recuperar — indexar lo necesario y filtrar por producto, país, idioma, vigencia, permiso y uso.
- 5. Responder o abstenerse — exigir cita interna y detenerse cuando falte evidencia, haya conflicto o la fuente esté vencida.
- 6. Aprobar y publicar — mostrar salida, fuente, transformación y riesgo; registrar la decisión.
- 7. Aprender — devolver correcciones, preguntas sin respuesta y desempeño del activo al backlog.
OpenAI documenta flujos que fragmentan, convierten en embeddings, indexan, buscan semánticamente y filtran archivos por atributos. Google describe etapas similares desde ingestión y transformación hasta recuperación y generación. La infraestructura existe en distintas plataformas. Autoridad, metadatos, evaluación y rutina de actualización siguen siendo trabajo de implementación.
Pruebe con preguntas diseñadas para fallar
Prepare un conjunto de evaluación antes de conectar el copiloto al trabajo real. Incluya preguntas simples, versiones enfrentadas, fuente vencida, países distintos, claim sin evidencia, instrucción para ignorar política y una duda legítima todavía sin respuesta. Para cada caso, registre fuente esperada, respuesta aceptable, motivo de abstención y revisor competente. Repita el mismo conjunto cuando cambie modelo, índice, prompt o fuente.
- Recuperación — ¿apareció la fuente correcta y quedó fuera la versión reemplazada?
- Fundamentación — ¿cada afirmación material está respaldada por la fuente mostrada?
- Abstención — ¿el sistema se detiene cuando falta evidencia, permiso o vigencia?
- Consistencia — ¿preguntas equivalentes aplican la misma regla en los canales y países correctos?
- Operación — ¿el responsable puede auditar el historial y propagar una corrección?
El perfil de NIST trata evaluación y monitoreo como trabajo de todo el ciclo de vida de IA generativa. Aquí implica probar antes del uso, observar fallas en producción, registrar cambios de fuente y poder suspender el flujo. Una demo pulida con cinco preguntas cómodas no demuestra una operación confiable.
Un alcance contratable de ocho semanas
- Semanas 1–2: elegir flujo, producto y país; medir la línea base; inventariar fuentes, conflictos, responsables y accesos.
- Semanas 3–4: definir contrato, jerarquía de autoridad, vigencia, permisos, ingestión y política de eliminación.
- Semanas 5–6: integrar una interfaz de trabajo, operar en modo sombra y ejecutar evaluación y casos adversos.
- Semanas 7–8: liberar un uso acotado, medir calidad y tiempo, corregir propagación, documentar operación y decidir ampliar, ajustar o detener.
La entrega debe incluir mapa de fuentes, schema, contenido priorizado, reglas de autoridad, conectores, índice y filtros, conjunto de evaluación, logs, tablero, runbook, cola de excepciones y mantenimiento. Ocho semanas delimitan el primer flujo; no prometen limpiar todo el conocimiento de la empresa ni eliminar errores del modelo.
Qué determina costo y arquitectura
El costo crece con fuentes, formatos, productos, marcas, países e idiomas; calidad de metadatos; frecuencia de cambio; permisos por rol; conectores; OCR; volumen de uso; modelo e infraestructura; evaluación humana; privacidad; y cantidad de sistemas que deben recibir correcciones. La licencia del copiloto es una línea.
Centralizar simplifica descubrimiento, pero amplía migración y gobierno. Consultar fuentes donde viven reduce copias, aunque depende de disponibilidad y APIs. RAG administrado acelera el piloto y aumenta dependencia; una capa propia mejora portabilidad con más operación. Un grafo de conocimiento expresa relaciones complejas, pero suele ser excesivo al comenzar. Elija la arquitectura mínima que preserve autoridad, filtros, trazabilidad y evaluación.
Mida capacidad y resultado por separado
- Calidad — fuente correcta, claim respaldado, conflicto detectado, abstención adecuada y error por clase.
- Operación — tiempo hasta aprobación, horas de revisión, retrabajo, edad de la fuente y tiempo para propagar una corrección.
- Adopción útil — tareas reales completadas y salidas aprobadas efectivamente usadas, no inicios de sesión.
- Negocio — ciclo de campaña, costo por activo usado, conversión o ingreso del flujo elegido, con línea base y comparación compatibles.
Si mejora la respuesta pero la aprobación sigue detenida o el activo no llega al canal, el cuello está fuera de la capa. Si el ciclo acelera y el resultado comercial no cambia, revise propuesta, distribución o medición antes de ampliar. Atribuya desempeño al flujo completo, no al modelo aislado.
Quién responde por la implementación
Marketing es dueño de casos, calidad y resultado. Producto, ventas y especialistas responden por los hechos. Legal y privacidad fijan límites cuando corresponde. Contenido y marca mantienen lenguaje y evidencia. Tecnología gestiona identidad, conectores, acceso, recuperación y observabilidad. La agencia o consultora debe unir responsabilidades, implementar un flujo real y dejar operación clara; no entregar solo una demo de chat.
Al comparar propuestas, pida demostrar cinco situaciones: fuentes en conflicto, claim vencido, corrección urgente, pregunta sin respuesta y variante para otro país. Observe si el sistema cita origen, respeta filtros, se abstiene, actualiza dependencias y registra la decisión. Esa prueba apoya el proyecto sin convertirlo en otro proceso genérico de selección.
Lleve el conocimiento problemático a la primera conversación
Use el plan inicial en https://makinai.co/insights/es/por-donde-empezar-ia-marketing-plan-90-dias, conecte la capa con producción en https://makinai.co/insights/es/ia-flujo-produccion-campanas-brief-lanzamiento y revise requisitos en https://makinai.co/insights/es/evaluar-preparacion-datos-antes-contratar-empresa-ia. Para publicar y hacer encontrable la misma evidencia, vea https://makinai.co/insights/es/empresa-google-no-respuestas-ia-plan-geo. MAKINAI implementa arquitectura de datos, contenido e inteligencia: https://makinai.co/services/es/datos-contenido-inteligencia-artificial. Traiga diez preguntas que producen respuestas divergentes y las fuentes actuales; podemos delimitar el primer flujo.
Las fuentes respaldan componentes de recuperación, etapas de RAG, procedencia y gestión de riesgo. No prueban que una capa particular reduzca retrabajo o aumente ingresos. El contrato, alcance, métricas y trade-offs son recomendaciones editoriales de MAKINAI que deben validarse con contenido, sistemas y usuarios reales.