--- title: "B2B y B2C en el mismo stack: cuándo separar agentes y conexiones" description: "Cómo separar agentes, conocimiento y conectores por audiencia cuando B2B y B2C comparten CRM, canales o back office." author: "Carlos García" published: 2026-09-23 updated: 2026-09-23 language: es human_url: "https://kiia.cloud/es/blog/b2b-b2c-separar-agentes-y-conexiones/" --- > **En 60 segundos:** Separá B2B y B2C cuando cambien las fuentes de verdad, los permisos, los canales o el responsable humano. Dos CRMs pueden ser un buen límite inicial, pero solo si el agente usa credenciales, conectores e índices distintos. Si ambos mundos convergen en un back office, publicá una vista o API por audiencia: el agente B2C no debería recibir nombres de tablas, campos ni resultados B2B. El prompt ayuda a orientar el comportamiento; la barrera debe vivir en la capa de datos y herramientas. Un solo agente puede bastar cuando las políticas son compatibles y cada solicitud obtiene herramientas acotadas según la identidad del usuario. Antes de producción, probá inyección de instrucciones, búsquedas cruzadas, logs, permisos y traspasos humanos. Una empresa puede vender contratos complejos a otras empresas y, al mismo tiempo, atender compras directas de consumidores. El CRM B2B guarda cuentas, oportunidades, condiciones negociadas y responsables comerciales. El entorno B2C trabaja con pedidos, campañas, soporte y preferencias de contacto. Ambos terminan consultando inventario, facturación o catálogo en el mismo back office. El problema aparece cuando una sola configuración de agente recibe acceso a los dos lados. Una pregunta legítima de soporte podría arrastrar una nota comercial que no corresponde a ese consumidor. Un documento recuperado podría incluir una instrucción maliciosa que intente cambiar el comportamiento del agente. Un historial largo podría reutilizar contexto de una audiencia en la siguiente conversación. [OWASP incluye la inyección de prompts y la divulgación de información sensible](https://genai.owasp.org/llm-top-10/) entre los riesgos de las aplicaciones con modelos de lenguaje. El impacto depende de los datos y acciones disponibles. Mantené fuera de alcance los datos y herramientas que esa audiencia no necesita, aunque el prompt ya indique a quién atiende el agente. ## La separación empieza en cinco fronteras La guía sobre [un agente generalista o varios especialistas](/es/blog/agente-generalista-vs-agentes-especializados/) compara contexto, coste, latencia y mantenimiento por función. Aquí la frontera es otra: dos agentes pueden hacer la misma tarea, como buscar un producto o preparar una respuesta, y aun así necesitar separación porque atienden poblaciones con datos y políticas distintos. | Frontera | Pregunta de diseño | Señal para separar | | --- | --- | --- | | Audiencia | ¿Quién hace la petición y qué relación tiene con la empresa? | Un consumidor no debería aparecer en búsquedas de cuentas B2B, o viceversa | | Permisos | ¿Qué registros, campos y acciones necesita esa identidad? | Una audiencia requiere condiciones, notas o escritura que la otra no debe recibir | | Fuente de verdad | ¿Qué sistema decide el estado del cliente, pedido u oportunidad? | B2B y B2C usan CRMs, esquemas o reglas de resolución diferentes | | Canal | ¿Por dónde entra y sale la interacción? | Cada canal tiene plantillas, consentimiento, horarios o responsables propios | | Ownership humano | ¿Quién revisa una excepción y quién puede aprobar una acción? | Equipos distintos responden por errores, escalaciones o compromisos | No hace falta que las cinco fronteras sean diferentes. Si solo cambia el tono de la respuesta, una plantilla por audiencia puede ser suficiente. Si cambian los permisos o la fuente de verdad, la separación debería existir fuera del prompt. ## Dos CRMs ayudan, pero no garantizan aislamiento Los silos existentes son un punto de partida útil. Un CRM comercial y otro de consumo ya tienen modelos de datos, responsables y ciclos de cambio distintos. Se pueden aprovechar como límites naturales: - una identidad de servicio por CRM, sin una cuenta compartida con acceso global - un conector y una lista de operaciones permitidas por audiencia - índices de búsqueda separados, con su propio proceso de ingestión y borrado - logs que indiquen qué identidad consultó qué fuente y para qué solicitud - colas de revisión dirigidas al equipo que es dueño del proceso El aislamiento se pierde si ambos conectores usan la misma credencial administrativa, si todos los documentos terminan en un índice común sin filtros verificables o si el agente puede consultar una base intermedia con las dos poblaciones. También se pierde cuando una persona copia datos B2B dentro de una conversación B2C: el límite técnico no corrige una práctica operativa incompatible. El principio de [mínimo privilegio de NIST](https://csrc.nist.gov/glossary/term/least_privilege) restringe a cada usuario o proceso a los recursos y autorizaciones necesarios para su tarea. Aplicado aquí, el agente B2C debería operar como una identidad B2C real. Una etiqueta en sus instrucciones no sustituye esa identidad. ## Un conector por audiencia es una política ejecutable "Conector" no tiene que significar dos productos o dos despliegues completos. Puede ser la misma plataforma de integración con dos configuraciones independientes. Cada una debería fijar: - credencial y audiencia autorizada - operaciones de lectura y escritura disponibles - campos que entran y salen - filtros obligatorios que el modelo no puede quitar - límites de volumen y tiempo - propietario, alertas y procedimiento de revocación Conviene que las herramientas expresen intención de negocio. `buscar_pedido_b2c` puede aceptar el identificador de pedido y la identidad verificada del consumidor. `buscar_oportunidad_b2b` puede exigir cuenta y propietario comercial. Una herramienta genérica como `consultar_base(sql)` obliga al modelo a resolver autorización y consultas a la vez, y expone una superficie mucho mayor. La aplicación debe comprobar permisos en cada llamada. El modelo puede seleccionar una herramienta incorrecta o recibir contenido que intente convencerlo de hacerlo. [OWASP explica que RAG o el ajuste del modelo no eliminan por completo la inyección de prompts](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). Las credenciales, allowlists y validaciones del conector siguen aplicándose aunque las instrucciones del modelo cambien. ## Cómo compartir el back office sin compartir su esquema Inventario, productos o facturación suelen vivir en un sistema común. Duplicarlo para cada audiencia puede crear inconsistencias y más trabajo. La alternativa es publicar contratos de acceso separados sobre el mismo back office. Imaginemos estas dos vistas: | Superficie B2B | Superficie B2C | | --- | --- | | Disponibilidad por almacén y fecha prometida | Disponibilidad pública o apta para venta directa | | Lista y condiciones autorizadas para la cuenta | Precio y promoción vigentes para el canal de consumo | | Estado de pedido vinculado a una cuenta | Estado de pedido vinculado a la identidad verificada | | Referencia del ejecutivo responsable | Referencia del equipo de soporte o autoservicio | La capa de servicio aplica filtros de fila y columna, valida la identidad y devuelve un resultado mínimo. El agente B2C no recibe acceso al catálogo de tablas, al esquema B2B ni a una herramienta de exploración. Tampoco necesita "saber que no debe" consultar una tabla B2B: esa tabla no forma parte de su vocabulario de herramientas. Puede haber datos compartidos, como una ficha pública de producto. En ese caso conviene mantener una fuente aprobada para ambos y separar únicamente los atributos restringidos. La guía sobre [asistentes técnicos sin exponer datos sensibles](/es/blog/asistente-ia-fichas-tecnicas-seguridad/) explica cómo clasificar documentos, filtrar la recuperación y conservar la procedencia de cada respuesta. Los logs también necesitan límites. Un registro de depuración que copie prompts, resultados completos y tokens de acceso puede reconstruir la mezcla que la arquitectura intentaba evitar. Registrá identificadores, versión de política, herramienta, resultado operativo y decisión de acceso. Conservá el contenido solo cuando sea necesario, con retención y permisos definidos. ## Cuándo un solo agente sigue siendo razonable Separar aumenta el número de identidades, configuraciones, evaluaciones y rutas de escalación. Dos agentes pueden compartir infraestructura, proveedor de modelo, despliegue y observabilidad, pero alguien debe mantener sus contratos y comprobar que no diverjan sin intención. Un solo agente puede funcionar cuando: - la identidad de la persona se verifica antes de construir el contexto - la aplicación decide qué conjunto de herramientas entrega en cada solicitud - las audiencias comparten políticas y fuente de verdad para esa tarea concreta - la memoria se limita a la conversación o cuenta autorizada - las pruebas cubren cambios de audiencia, datos ambiguos y llamadas fuera de alcance Por ejemplo, un agente de solo lectura puede responder desde un catálogo público y consultar el estado de un pedido mediante una herramienta que valida la identidad. No necesita dos personalidades si nunca recibe datos B2B y la aplicación no le ofrece herramientas B2B durante esa sesión. La separación gana valor cuando una sola ejecución necesitaría acceso simultáneo a los dos dominios, cuando una audiencia tiene escritura y la otra no, o cuando los equipos necesitan aprobar y evaluar cambios por separado. El coste relevante incluye desarrollo, gestión de secretos, monitorización y soporte. El riesgo de un único stack incluye el alcance de una credencial, la cantidad de datos accesibles y cuántos casos puede afectar un error antes de ser detectado. ## Asigná el nivel de control a cada acción Separar audiencias no decide cuánta autonomía recibe el agente. Un agente B2B puede leer oportunidades, proponer un seguimiento o enviar una comunicación; son acciones con consecuencias distintas. Lo mismo ocurre con devoluciones, cambios de dirección o cancelaciones en B2C. El marco de [cinco niveles de control](/es/blog/copiloto-o-piloto-automatico-agentes-ia/) ayuda a asignar lectura, recomendación, borrador, ejecución aprobada o autonomía acotada a cada operación. Una separación correcta de datos no convierte una acción irreversible en segura. Los límites de audiencia y los límites de ejecución se diseñan por separado y se prueban juntos. El CRM debería conservar el estado comercial, el responsable y el próximo paso. El canal transporta la conversación. Nuestro artículo sobre [CRM como fuente de verdad](/es/blog/crm-verdad-whatsapp-canal-seguimiento-inbound/) detalla ese reparto y evita que el historial de mensajería se transforme en una segunda base de datos sin gobierno. ## Checklist antes de producción ### Identidad y permisos - [ ] Cada audiencia usa una identidad de servicio y credenciales propias. - [ ] Las herramientas permiten únicamente las operaciones y campos necesarios. - [ ] Los filtros se aplican en la API o capa de datos, no solo en el prompt. - [ ] Existe un procedimiento probado para revocar accesos sin detener el otro flujo. ### Contexto, conocimiento y memoria - [ ] Los índices y procesos de ingestión conservan la clasificación de audiencia. - [ ] La memoria se delimita por usuario, cuenta, audiencia y duración autorizada. - [ ] Documentos y mensajes se tratan como contenido no confiable. - [ ] La ausencia de una fuente produce una respuesta acotada o un traspaso, no una búsqueda más amplia. ### Pruebas de fuga - [ ] Los casos intentan pedir nombres, registros y condiciones de la otra audiencia. - [ ] Las pruebas incluyen instrucciones maliciosas en mensajes y documentos recuperados. - [ ] Se cambia la identidad durante una conversación para comprobar que el contexto se reconstruye. - [ ] Las evaluaciones fallan si la respuesta revela un dato, confirma su existencia o llama a una herramienta fuera de alcance. ### Logs y operación - [ ] Cada llamada registra identidad, política, conector, resultado y correlación sin copiar secretos. - [ ] Las alertas detectan denegaciones repetidas, consultas anómalas y picos de volumen. - [ ] El equipo puede rastrear una respuesta hasta sus fuentes y versión de configuración. - [ ] La retención de logs y conversaciones tiene un responsable y una fecha de revisión. ### Handoff humano - [ ] Cada excepción tiene una cola, un equipo propietario y un SLA. - [ ] El traspaso comparte el mínimo contexto necesario y conserva la audiencia de origen. - [ ] Una persona puede corregir el registro en la fuente de verdad. - [ ] El procedimiento de incidente contempla pausar un conector sin bloquear al otro. Kiia puede mapear fuentes, identidades, conectores y responsables antes de elegir cuántos agentes desplegar. Nuestro enfoque de [integración de sistemas](/es/servicios/integracion-de-sistemas/) empieza con una matriz de acceso y casos reales de excepción. Ese mapa permite decidir dónde compartir infraestructura y dónde imponer una frontera que el modelo no pueda ampliar. ## Preguntas frecuentes ### ¿Tener CRMs separados evita que un agente mezcle datos B2B y B2C? Ayuda si cada CRM usa credenciales, conectores, índices y permisos distintos. No alcanza cuando el agente comparte una cuenta con acceso a ambos, consulta un back office sin filtros o recibe historiales mezclados. ### ¿Hace falta construir dos plataformas completas? No siempre. Las dos audiencias pueden compartir infraestructura, observabilidad y componentes comunes. La separación importante está en las identidades, fuentes de conocimiento, herramientas, permisos y colas de revisión que determinan qué puede ver y hacer cada agente. ### ¿Cuándo puede bastar un solo agente? Cuando ambas audiencias comparten políticas y fuente de verdad, los datos sensibles quedan fuera del contexto, las herramientas aplican permisos por identidad y los casos de prueba demuestran que no hay cruces de audiencia.