{ "generated": "2026-09-11T20:55:56.304Z", "count": 6, "license": "Content © Santiago Santa María Morales, licensed CC BY 4.0. Attribution required: credit the author and link the canonical URL.", "license_spdx": "CC-BY-4.0", "license_url": "https://creativecommons.org/licenses/by/4.0/", "entries": [ { "id": "ARCH-001", "slug": "customer-service-agent", "category": "customer-experience", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/architectures/customer-service-agent", "api": "https://santismm.com/api/architectures/customer-service-agent", "canonical_url": "https://santismm.com/en/architectures/customer-service-agent", "api_url": "https://santismm.com/api/architectures/customer-service-agent", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "medium", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "LangGraph / orchestration", "RAG over a help-center knowledge base", "CRM & ticketing tools (function calling)", "Vector store", "Guardrails / PII redaction", "Observability (LangSmith / Langfuse)" ], "patterns": [ "routing", "human-approval-gate", "semantic-caching", "reflection" ], "knowledge": [ "ai-agent", "tool-use", "enterprise-rag", "guardrails", "human-in-the-loop", "ai-observability" ], "references": [ { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" }, { "title": "Santiago Santa María — The Stopwatch and the Exam", "url": "https://articles.santismm.com/the-stopwatch-and-the-exam/" } ], "related": [ "enterprise-knowledge-assistant" ], "locales": { "en": { "name": "Customer Service Agent", "summary": "A reference architecture for an enterprise customer-service agent that resolves common requests end to end — answering from a grounded knowledge base, acting in the CRM and ticketing systems through tools, and escalating to a human when confidence is low or the action is high-impact. It pairs retrieval for grounding with risk-based human approval for safety, and is observable so every conversation can be evaluated and improved.", "keyConcepts": [ "Grounding: answers come from retrieved, citable knowledge, not the model's memory.", "Tool use: the agent reads and writes to CRM/ticketing systems through well-described tools.", "Risk-based escalation: low-confidence or high-impact actions go to a human gate.", "Observability: every turn is traced so the system can be evaluated and improved." ], "definition": "The customer service agent architecture is a grounded, tool-using conversational agent that resolves customer requests autonomously within guardrails, escalating to humans by risk and confidence, with full tracing for evaluation.", "architecture": [ "At the core is an orchestration loop that classifies the incoming request, retrieves relevant knowledge, decides whether it can answer or must act, and either responds, calls a tool, or escalates. Routing sends simple FAQs down a cheap retrieval-and-answer path and complex or sensitive cases down a richer, more careful path.", "Grounding is non-negotiable: the agent answers from a retrieval layer over the help center and policy docs, and cites its sources. When the request requires an action — issuing a refund, changing an order, closing a ticket — the agent prepares the action and routes high-impact ones through a human approval gate before execution.", "Cross-cutting layers make it safe and improvable: guardrails redact PII and block out-of-policy responses, a semantic cache absorbs repeated questions to cut cost and latency, and an observability layer traces every turn so conversations can be scored against an evaluation set." ], "flow": [ "1. Intake: the user message arrives; PII is detected and redacted for logging.", "2. Route: classify intent and risk — FAQ, account action, or escalation candidate.", "3. Retrieve: pull grounding passages from the knowledge base (cache-checked first).", "4. Decide: answer from grounding, call a CRM/ticketing tool, or escalate.", "5. Gate: high-impact actions pause for human approval; low-impact ones execute.", "6. Respond: reply with citations; log the trace and outcome for evaluation." ], "components": [ "Intent & risk router", "Retrieval layer (RAG) with citations", "CRM / ticketing tools", "Human approval gate", "Guardrails & PII redaction", "Semantic cache", "Observability & evaluation" ], "referenceScenario": { "context": "An illustrative B2C support desk handling order, billing and account questions across chat and email.", "scenario": "Tier-1 requests (order status, password reset, policy questions) are resolved by the agent; refunds and account changes are drafted by the agent and approved by a human; anything ambiguous is escalated with full context.", "technology": "Orchestration loop, RAG over the help center, function-calling tools into the CRM, a risk-based approval gate, and conversation tracing.", "load": "Bursty, business-hours-heavy traffic with a long tail of rare intents; a small set of FAQs dominates volume, which the semantic cache absorbs.", "results": "Reference target: most Tier-1 volume deflected with grounded, cited answers; high-impact actions kept behind a human gate; cost concentrated on the rare, complex cases rather than the repetitive ones. Numbers depend on your traffic mix and should be measured, not assumed." }, "benefits": [ "Resolves common requests end to end while keeping risky actions human-gated.", "Grounded, cited answers reduce hallucination and build customer trust.", "Semantic caching and routing concentrate spend on the cases that need it.", "Full tracing makes quality measurable and regressions catchable." ], "risks": [ "Ungrounded answers if retrieval quality is poor.", "Over-automation of actions that should stay human-gated.", "PII leakage if guardrails are incomplete.", "Approval bottlenecks if too many actions are gated." ], "failureModes": [ "Retrieval misses or returns stale policy, so the agent answers confidently but wrongly.", "Tool errors (CRM timeouts, schema drift) leave actions half-applied without recovery.", "Escalation overload when the router sends too much to humans, defeating the automation.", "Cache false hits return a previous customer's context or an out-of-date answer." ], "lessons": [ "Ground first: invest in retrieval quality before expanding autonomy — most wrong answers are retrieval failures.", "Gate by risk, not by default; reserve human approval for irreversible or regulated actions.", "Scope the cache per customer/context and validate hits, or it leaks the wrong answer.", "Instrument from day one; you cannot improve what you cannot trace." ], "kpis": [ { "metric": "Containment / deflection rate", "note": "Share of conversations resolved without a human; the headline value metric — but only meaningful alongside CSAT." }, { "metric": "Grounded-answer accuracy", "note": "How often answers are correct and supported by a citation, measured against an eval set." }, { "metric": "Escalation rate & quality", "note": "Share escalated to humans and whether those escalations were warranted; too high wastes the automation, too low risks bad outcomes." }, { "metric": "Cost per resolved conversation", "note": "Total tokens, tools and cache effect per resolution; routing and caching should keep this low on the common path." }, { "metric": "CSAT / resolution time", "note": "Customer satisfaction and time-to-resolution; guards against optimizing deflection at the expense of experience." } ], "scaling": [ "Volume scales with the stateless orchestration loop; the vector store and tool backends are the real capacity limits.", "The semantic cache flattens cost as repeat questions grow, so unit cost falls with scale on the common path.", "Human approval is the bottleneck that does not scale linearly — keep the gated set small and triaged.", "Cost is dominated by the rare, complex conversations, not the cached FAQ majority." ], "examples": [ "An order-status question answered instantly from the cache with a citation.", "A refund the agent drafts and a human approves before it is issued.", "An ambiguous billing dispute escalated to an agent with the full conversation context attached." ], "faqs": [ { "q": "How is this different from a chatbot?", "a": "A chatbot answers; this architecture also acts — it uses tools to read and write enterprise systems — and it grounds answers in retrieved knowledge, escalating by risk rather than following fixed scripts." }, { "q": "Why keep a human in the loop at all?", "a": "Because some actions are irreversible or regulated. A risk-based approval gate keeps accountability with a person for high-impact steps while automating the safe majority." }, { "q": "What makes it reliable?", "a": "Grounding in retrieval, guardrails on inputs and outputs, and observability that lets you evaluate every conversation and catch regressions before they ship." } ] }, "es": { "name": "Agente de Atención al Cliente", "summary": "Una arquitectura de referencia para un agente empresarial de atención al cliente que resuelve solicitudes comunes de extremo a extremo: responde desde una base de conocimiento fundamentada, actúa en el CRM y los sistemas de tickets mediante herramientas, y escala a un humano cuando la confianza es baja o la acción es de alto impacto. Combina recuperación para fundamentar las respuestas con aprobación humana basada en riesgo para la seguridad, y es observable para evaluar y mejorar cada conversación.", "keyConcepts": [ "Fundamentación: las respuestas vienen de conocimiento recuperado y citable, no de la memoria del modelo.", "Uso de herramientas: el agente lee y escribe en CRM/tickets mediante herramientas bien descritas.", "Escalado basado en riesgo: las acciones de baja confianza o alto impacto pasan por una puerta humana.", "Observabilidad: cada turno se traza para poder evaluar y mejorar el sistema." ], "definition": "La arquitectura de agente de atención al cliente es un agente conversacional fundamentado y con herramientas que resuelve solicitudes de forma autónoma dentro de guardarraíles, escalando a humanos por riesgo y confianza, con trazado completo para evaluación.", "architecture": [ "En el núcleo hay un bucle de orquestación que clasifica la solicitud entrante, recupera conocimiento relevante, decide si puede responder o debe actuar, y o bien responde, llama a una herramienta o escala. El enrutado envía las FAQ simples a un camino barato de recuperar-y-responder y los casos complejos o sensibles a un camino más rico y cuidadoso.", "La fundamentación es innegociable: el agente responde desde una capa de recuperación sobre el centro de ayuda y las políticas, y cita sus fuentes. Cuando la solicitud requiere una acción —emitir un reembolso, cambiar un pedido, cerrar un ticket— el agente prepara la acción y enruta las de alto impacto por una puerta de aprobación humana antes de ejecutarlas.", "Las capas transversales lo hacen seguro y mejorable: los guardarraíles redactan PII y bloquean respuestas fuera de política, una caché semántica absorbe preguntas repetidas para reducir coste y latencia, y una capa de observabilidad traza cada turno para puntuar conversaciones contra un conjunto de evaluación." ], "flow": [ "1. Entrada: llega el mensaje del usuario; se detecta y redacta la PII para el registro.", "2. Enrutar: clasificar intención y riesgo — FAQ, acción de cuenta o candidato a escalado.", "3. Recuperar: traer pasajes de fundamentación de la base de conocimiento (con caché comprobada primero).", "4. Decidir: responder con fundamentación, llamar a una herramienta de CRM/tickets o escalar.", "5. Puerta: las acciones de alto impacto se pausan para aprobación humana; las de bajo impacto se ejecutan.", "6. Responder: contestar con citas; registrar la traza y el resultado para evaluación." ], "components": [ "Router de intención y riesgo", "Capa de recuperación (RAG) con citas", "Herramientas de CRM / tickets", "Puerta de aprobación humana", "Guardarraíles y redacción de PII", "Caché semántica", "Observabilidad y evaluación" ], "referenceScenario": { "context": "Una mesa de soporte B2C ilustrativa que atiende preguntas de pedidos, facturación y cuenta por chat y correo.", "scenario": "Las solicitudes de Nivel 1 (estado de pedido, restablecer contraseña, preguntas de política) las resuelve el agente; los reembolsos y cambios de cuenta los redacta el agente y los aprueba un humano; lo ambiguo se escala con contexto completo.", "technology": "Bucle de orquestación, RAG sobre el centro de ayuda, herramientas de function-calling hacia el CRM, una puerta de aprobación basada en riesgo y trazado de conversaciones.", "load": "Tráfico irregular y concentrado en horario laboral, con una larga cola de intenciones raras; un pequeño conjunto de FAQ domina el volumen, que la caché semántica absorbe.", "results": "Objetivo de referencia: desviar la mayor parte del volumen de Nivel 1 con respuestas fundamentadas y citadas; mantener las acciones de alto impacto tras una puerta humana; concentrar el coste en los casos raros y complejos en vez de los repetitivos. Los números dependen de tu mezcla de tráfico y deben medirse, no asumirse." }, "benefits": [ "Resuelve solicitudes comunes de extremo a extremo manteniendo las acciones de riesgo con puerta humana.", "Las respuestas fundamentadas y citadas reducen la alucinación y generan confianza.", "La caché semántica y el enrutado concentran el gasto en los casos que lo necesitan.", "El trazado completo hace medible la calidad y detectables las regresiones." ], "risks": [ "Respuestas sin fundamentación si la calidad de la recuperación es pobre.", "Sobreautomatización de acciones que deberían seguir con puerta humana.", "Fuga de PII si los guardarraíles son incompletos.", "Cuellos de botella de aprobación si se ponen puertas a demasiadas acciones." ], "failureModes": [ "La recuperación falla o devuelve política obsoleta, así que el agente responde con confianza pero mal.", "Errores de herramienta (timeouts del CRM, deriva de esquema) dejan acciones a medio aplicar sin recuperación.", "Sobrecarga de escalado cuando el router envía demasiado a humanos, anulando la automatización.", "Falsos aciertos de caché devuelven el contexto de un cliente anterior o una respuesta desactualizada." ], "lessons": [ "Fundamenta primero: invierte en la calidad de la recuperación antes de ampliar la autonomía; la mayoría de respuestas erróneas son fallos de recuperación.", "Pon puertas por riesgo, no por defecto; reserva la aprobación humana para acciones irreversibles o reguladas.", "Acota la caché por cliente/contexto y valida los aciertos, o filtrará la respuesta equivocada.", "Instrumenta desde el día uno; no puedes mejorar lo que no puedes trazar." ], "kpis": [ { "metric": "Tasa de contención / desviación", "note": "Proporción de conversaciones resueltas sin un humano; la métrica de valor principal, pero solo significativa junto al CSAT." }, { "metric": "Precisión de respuesta fundamentada", "note": "Con qué frecuencia las respuestas son correctas y respaldadas por una cita, medido contra un conjunto de evaluación." }, { "metric": "Tasa y calidad de escalado", "note": "Proporción escalada a humanos y si esos escalados estaban justificados; demasiado alto desperdicia la automatización, demasiado bajo arriesga malos resultados." }, { "metric": "Coste por conversación resuelta", "note": "Tokens, herramientas y efecto de caché totales por resolución; el enrutado y la caché deben mantenerlo bajo en el camino común." }, { "metric": "CSAT / tiempo de resolución", "note": "Satisfacción del cliente y tiempo hasta la resolución; evita optimizar la desviación a costa de la experiencia." } ], "scaling": [ "El volumen escala con el bucle de orquestación sin estado; el almacén vectorial y los backends de herramientas son los límites reales de capacidad.", "La caché semántica aplana el coste a medida que crecen las preguntas repetidas, así que el coste unitario baja con la escala en el camino común.", "La aprobación humana es el cuello de botella que no escala linealmente; mantén el conjunto con puerta pequeño y triado.", "El coste lo dominan las conversaciones raras y complejas, no la mayoría de FAQ en caché." ], "examples": [ "Una pregunta de estado de pedido respondida al instante desde la caché con una cita.", "Un reembolso que el agente redacta y un humano aprueba antes de emitirse.", "Una disputa de facturación ambigua escalada a un agente con todo el contexto de la conversación adjunto." ], "faqs": [ { "q": "¿En qué se diferencia de un chatbot?", "a": "Un chatbot responde; esta arquitectura además actúa —usa herramientas para leer y escribir en sistemas empresariales— y fundamenta las respuestas en conocimiento recuperado, escalando por riesgo en vez de seguir guiones fijos." }, { "q": "¿Por qué mantener un humano en el bucle?", "a": "Porque algunas acciones son irreversibles o reguladas. Una puerta de aprobación basada en riesgo mantiene la responsabilidad en una persona para los pasos de alto impacto mientras automatiza la mayoría segura." }, { "q": "¿Qué la hace fiable?", "a": "La fundamentación en la recuperación, los guardarraíles en entradas y salidas, y la observabilidad que permite evaluar cada conversación y detectar regresiones antes de desplegar." } ] }, "pt": { "name": "Agente de Atendimento ao Cliente", "summary": "Uma arquitetura de referência para um agente empresarial de atendimento que resolve solicitações comuns de ponta a ponta: responde a partir de uma base de conhecimento fundamentada, age no CRM e nos sistemas de tickets via ferramentas, e escala para um humano quando a confiança é baixa ou a ação é de alto impacto. Combina recuperação para fundamentar as respostas com aprovação humana baseada em risco para segurança, e é observável para avaliar e melhorar cada conversa.", "keyConcepts": [ "Fundamentação: as respostas vêm de conhecimento recuperado e citável, não da memória do modelo.", "Uso de ferramentas: o agente lê e escreve no CRM/tickets via ferramentas bem descritas.", "Escalonamento baseado em risco: ações de baixa confiança ou alto impacto passam por um portão humano.", "Observabilidade: cada turno é rastreado para avaliar e melhorar o sistema." ], "definition": "A arquitetura de agente de atendimento é um agente conversacional fundamentado e com ferramentas que resolve solicitações de forma autônoma dentro de guard-rails, escalando para humanos por risco e confiança, com rastreamento completo para avaliação.", "architecture": [ "No núcleo há um loop de orquestração que classifica a solicitação recebida, recupera conhecimento relevante, decide se pode responder ou deve agir, e então responde, chama uma ferramenta ou escala. O roteamento envia FAQs simples a um caminho barato de recuperar-e-responder e os casos complexos ou sensíveis a um caminho mais rico e cuidadoso.", "A fundamentação é inegociável: o agente responde a partir de uma camada de recuperação sobre a central de ajuda e as políticas, e cita suas fontes. Quando a solicitação exige uma ação —emitir um reembolso, mudar um pedido, fechar um ticket— o agente prepara a ação e roteia as de alto impacto por um portão de aprovação humana antes de executar.", "As camadas transversais o tornam seguro e melhorável: os guard-rails redigem PII e bloqueiam respostas fora da política, um cache semântico absorve perguntas repetidas para reduzir custo e latência, e uma camada de observabilidade rastreia cada turno para pontuar conversas contra um conjunto de avaliação." ], "flow": [ "1. Entrada: chega a mensagem do usuário; a PII é detectada e redigida para o log.", "2. Rotear: classificar intenção e risco — FAQ, ação de conta ou candidato a escalonamento.", "3. Recuperar: trazer trechos de fundamentação da base de conhecimento (com cache verificado primeiro).", "4. Decidir: responder com fundamentação, chamar uma ferramenta de CRM/tickets ou escalar.", "5. Portão: ações de alto impacto pausam para aprovação humana; as de baixo impacto executam.", "6. Responder: responder com citações; registrar o rastro e o resultado para avaliação." ], "components": [ "Roteador de intenção e risco", "Camada de recuperação (RAG) com citações", "Ferramentas de CRM / tickets", "Portão de aprovação humana", "Guard-rails e redação de PII", "Cache semântico", "Observabilidade e avaliação" ], "referenceScenario": { "context": "Uma mesa de suporte B2C ilustrativa que atende perguntas de pedidos, faturamento e conta por chat e e-mail.", "scenario": "As solicitações de Nível 1 (status do pedido, redefinir senha, perguntas de política) são resolvidas pelo agente; reembolsos e mudanças de conta são redigidos pelo agente e aprovados por um humano; o ambíguo é escalado com contexto completo.", "technology": "Loop de orquestração, RAG sobre a central de ajuda, ferramentas de function-calling para o CRM, um portão de aprovação baseado em risco e rastreamento de conversas.", "load": "Tráfego irregular e concentrado no horário comercial, com uma longa cauda de intenções raras; um pequeno conjunto de FAQs domina o volume, que o cache semântico absorve.", "results": "Meta de referência: desviar a maior parte do volume de Nível 1 com respostas fundamentadas e citadas; manter as ações de alto impacto atrás de um portão humano; concentrar o custo nos casos raros e complexos em vez dos repetitivos. Os números dependem da sua mistura de tráfego e devem ser medidos, não assumidos." }, "benefits": [ "Resolve solicitações comuns de ponta a ponta mantendo as ações de risco com portão humano.", "Respostas fundamentadas e citadas reduzem a alucinação e geram confiança.", "O cache semântico e o roteamento concentram o gasto nos casos que precisam.", "O rastreamento completo torna a qualidade mensurável e as regressões detectáveis." ], "risks": [ "Respostas sem fundamentação se a qualidade da recuperação for ruim.", "Superautomação de ações que deveriam continuar com portão humano.", "Vazamento de PII se os guard-rails forem incompletos.", "Gargalos de aprovação se houver portões em ações demais." ], "failureModes": [ "A recuperação falha ou devolve política obsoleta, então o agente responde com confiança mas errado.", "Erros de ferramenta (timeouts do CRM, deriva de esquema) deixam ações pela metade sem recuperação.", "Sobrecarga de escalonamento quando o roteador envia demais a humanos, anulando a automação.", "Falsos acertos de cache devolvem o contexto de um cliente anterior ou uma resposta desatualizada." ], "lessons": [ "Fundamente primeiro: invista na qualidade da recuperação antes de ampliar a autonomia; a maioria das respostas erradas são falhas de recuperação.", "Coloque portões por risco, não por padrão; reserve a aprovação humana para ações irreversíveis ou reguladas.", "Restrinja o cache por cliente/contexto e valide os acertos, ou ele vazará a resposta errada.", "Instrumente desde o dia um; você não pode melhorar o que não consegue rastrear." ], "kpis": [ { "metric": "Taxa de contenção / desvio", "note": "Proporção de conversas resolvidas sem um humano; a métrica de valor principal, mas só significativa junto ao CSAT." }, { "metric": "Precisão de resposta fundamentada", "note": "Com que frequência as respostas são corretas e apoiadas por uma citação, medido contra um conjunto de avaliação." }, { "metric": "Taxa e qualidade de escalonamento", "note": "Proporção escalada a humanos e se esses escalonamentos eram justificados; alto demais desperdiça a automação, baixo demais arrisca maus resultados." }, { "metric": "Custo por conversa resolvida", "note": "Tokens, ferramentas e efeito do cache totais por resolução; o roteamento e o cache devem mantê-lo baixo no caminho comum." }, { "metric": "CSAT / tempo de resolução", "note": "Satisfação do cliente e tempo até a resolução; evita otimizar o desvio às custas da experiência." } ], "scaling": [ "O volume escala com o loop de orquestração sem estado; o armazenamento vetorial e os backends de ferramentas são os limites reais de capacidade.", "O cache semântico achata o custo à medida que as perguntas repetidas crescem, então o custo unitário cai com a escala no caminho comum.", "A aprovação humana é o gargalo que não escala linearmente; mantenha o conjunto com portão pequeno e triado.", "O custo é dominado pelas conversas raras e complexas, não pela maioria de FAQ em cache." ], "examples": [ "Uma pergunta de status de pedido respondida na hora a partir do cache com uma citação.", "Um reembolso que o agente redige e um humano aprova antes de ser emitido.", "Uma disputa de faturamento ambígua escalada a um agente com todo o contexto da conversa anexado." ], "faqs": [ { "q": "Como difere de um chatbot?", "a": "Um chatbot responde; esta arquitetura também age —usa ferramentas para ler e escrever em sistemas empresariais— e fundamenta as respostas em conhecimento recuperado, escalando por risco em vez de seguir roteiros fixos." }, { "q": "Por que manter um humano no laço?", "a": "Porque algumas ações são irreversíveis ou reguladas. Um portão de aprovação baseado em risco mantém a responsabilidade com uma pessoa nos passos de alto impacto enquanto automatiza a maioria segura." }, { "q": "O que a torna confiável?", "a": "A fundamentação na recuperação, os guard-rails em entradas e saídas, e a observabilidade que permite avaliar cada conversa e detectar regressões antes de implantar." } ] }, "fr": { "name": "Agent de service client", "summary": "Une architecture de référence pour un agent de service client d'entreprise qui résout les requêtes courantes de bout en bout : il répond à partir d'une base de connaissances ancrée, agit dans le CRM et les systèmes de tickets via des outils, et escalade vers un humain lorsque le niveau de confiance est faible ou que l'action a un impact élevé. Elle associe la recherche pour l'ancrage à une approbation humaine basée sur le risque pour la sécurité, et est observable afin que chaque conversation puisse être évaluée et améliorée.", "keyConcepts": [ "Ancrage (grounding) : les réponses proviennent de connaissances récupérées et citables, et non de la mémoire du modèle.", "Utilisation d'outils : l'agent lit et écrit dans les systèmes de CRM/tickets via des outils bien décrits.", "Escalade basée sur le risque : les actions à faible confiance ou à fort impact sont soumises à une validation humaine.", "Observabilité : chaque échange est tracé afin que le système puisse être évalué et amélioré." ], "definition": "L'architecture de l'agent de service client est un agent conversationnel ancré utilisant des outils, qui résout les requêtes des clients de manière autonome dans le cadre de garde-fous, escalade vers des humains selon le risque et le niveau de confiance, avec un traçage complet pour l'évaluation.", "architecture": [ "Au cœur du système se trouve une boucle d'orchestration qui classifie la requête entrante, récupère les connaissances pertinentes, décide s'il peut répondre ou s'il doit agir, puis répond, appelle un outil ou escalade. L'aiguillage (routing) oriente les FAQ simples vers un parcours économique de recherche et réponse, et les cas complexes ou sensibles vers un parcours plus riche et plus prudent.", "L'ancrage est non négociable : l'agent répond à partir d'une couche de recherche couvrant le centre d'aide et les documents de politique interne, et cite ses sources. Lorsque la requête nécessite une action (effectuer un remboursement, modifier une commande, fermer un ticket), l'agent prépare l'action et oriente celles à fort impact vers une validation humaine avant exécution.", "Des couches transversales garantissent la sécurité et l'évolutivité : des garde-fous masquent les données personnelles (PII) et bloquent les réponses non conformes aux politiques, un cache sémantique absorbe les questions répétitives pour réduire les coûts et la latence, et une couche d'observabilité trace chaque échange afin que les conversations puissent être évaluées par rapport à un jeu de test." ], "flow": [ "1. Réception : le message de l'utilisateur arrive ; les données personnelles (PII) sont détectées et masquées pour la journalisation.", "2. Aiguillage : classification de l'intention et du risque (FAQ, action sur le compte ou candidat à l'escalade).", "3. Recherche : récupération des passages d'ancrage dans la base de connaissances (après vérification du cache).", "4. Décision : répondre à partir de l'ancrage, appeler un outil de CRM/tickets ou escalader.", "5. Validation : les actions à fort impact sont suspendues dans l'attente d'une approbation humaine ; celles à faible impact sont exécutées.", "6. Réponse : répondre en incluant les citations ; enregistrer la trace et le résultat pour évaluation." ], "components": [ "Routeur d'intention et de risque", "Couche de recherche (RAG) avec citations", "Outils de CRM / de gestion des tickets", "Étape de validation humaine", "Garde-fous et masquage des données personnelles (PII)", "Cache sémantique", "Observabilité et évaluation" ], "referenceScenario": { "context": "Un centre de support B2C illustratif gérant les questions relatives aux commandes, à la facturation et aux comptes via chat et e-mail.", "scenario": "Les requêtes de niveau 1 (statut de commande, réinitialisation de mot de passe, questions sur les politiques) sont résolues par l'agent ; les remboursements et les modifications de compte sont préparés par l'agent et approuvés par un humain ; tout cas ambigu est escaladé avec l'ensemble du contexte.", "technology": "Boucle d'orchestration, RAG sur le centre d'aide, outils d'appel de fonctions vers le CRM, étape de validation basée sur le risque et traçage des conversations.", "load": "Trafic irrégulier, concentré sur les heures de bureau, avec une longue traîne d'intentions rares ; un petit ensemble de FAQ représente la majorité du volume, absorbé par le cache sémantique.", "results": "Cible de référence : la majeure partie du volume de niveau 1 est détournée grâce à des réponses ancrées et citées ; les actions à fort impact restent soumises à une validation humaine ; les coûts se concentrent sur les cas rares et complexes plutôt que sur les cas répétitifs. Les chiffres dépendent de la répartition de votre trafic et doivent être mesurés, non supposés." }, "benefits": [ "Résout les requêtes courantes de bout en bout tout en soumettant les actions risquées à une validation humaine.", "Les réponses ancrées et citées réduisent les hallucinations et renforcent la confiance des clients.", "La mise en cache sémantique et l'aiguillage concentrent les dépenses sur les cas qui le nécessitent.", "Le traçage complet rend la qualité mesurable et permet de détecter les régressions." ], "risks": [ "Réponses non ancrées si la qualité de la recherche est médiocre.", "Sur-automatisation d'actions qui devraient rester soumises à une validation humaine.", "Fuite de données personnelles (PII) si les garde-fous sont incomplets.", "Goulots d'étranglement au niveau des approbations si trop d'actions sont soumises à validation." ], "failureModes": [ "La recherche échoue ou renvoie une politique obsolète, ce qui conduit l'agent à répondre avec assurance mais de manière erronée.", "Des erreurs d'outils (délais d'attente CRM dépassés, dérive de schéma) laissent des actions appliquées à moitié sans possibilité de récupération.", "Surcharge d'escalades lorsque le routeur envoie trop de cas aux humains, ce qui annule les bénéfices de l'automatisation.", "Des correspondances erronées dans le cache renvoient le contexte d'un client précédent ou une réponse obsolète." ], "lessons": [ "Ancrez d'abord : investissez dans la qualité de la recherche avant d'étendre l'autonomie — la plupart des réponses erronées sont dues à des échecs de recherche.", "Valisez selon le risque, pas par défaut ; réservez l'approbation humaine aux actions irréversibles ou réglementées.", "Limitez la portée du cache par client/contexte et valisez les correspondances, sous peine de divulguer une réponse erronée.", "Instrumentez dès le premier jour ; vous ne pouvez pas améliorer ce que vous ne pouvez pas tracer." ], "kpis": [ { "metric": "Taux de résolution autonome / de déviation", "note": "Part des conversations résolues sans intervention humaine ; la métrique de valeur principale — mais qui n'a de sens qu'associée au CSAT." }, { "metric": "Précision des réponses ancrées", "note": "Fréquence à laquelle les réponses sont correctes et étayées par une citation, mesurée par rapport à un jeu de test." }, { "metric": "Taux et qualité des escalades", "note": "Part des requêtes escaladées vers des humains et pertinence de ces escalades ; un taux trop élevé annule l'intérêt de l'automatisation, un taux trop bas risque d'entraîner de mauvais résultats." }, { "metric": "Coût par conversation résolue", "note": "Total des jetons, des outils et de l'effet de cache par résolution ; l'aiguillage et la mise en cache doivent maintenir ce coût à un niveau bas sur le parcours classique." }, { "metric": "CSAT / temps de résolution", "note": "Satisfaction client et temps de résolution ; permet d'éviter d'optimiser la déviation au détriment de l'expérience utilisateur." } ], "scaling": [ "Le volume évolue avec la boucle d'orchestration sans état ; la base de données vectorielle et les backends d'outils constituent les véritables limites de capacité.", "Le cache sémantique stabilise les coûts à mesure que les questions répétitives augmentent, de sorte que le coût unitaire diminue avec l'échelle sur le parcours classique.", "L'approbation humaine est le goulot d'étranglement qui n'évolue pas de manière linéaire — limitez le nombre d'actions soumises à validation et triez-les.", "Le coût est dominé par les conversations rares et complexes, et non par la majorité des FAQ mises en cache." ], "examples": [ "Une question sur le statut d'une commande répondue instantanément depuis le cache avec une citation.", "Un remboursement que l'agent prépare et qu'un humain approuve avant qu'il ne soit émis.", "Un litige de facturation ambigu escaladé vers un conseiller avec l'ensemble du contexte de la conversation joint." ], "faqs": [ { "q": "En quoi cela diffère-t-il d'un chatbot ?", "a": "Un chatbot se contente de répondre ; cette architecture agit également — elle utilise des outils pour lire et écrire dans les systèmes de l'entreprise — et elle ancre ses réponses dans les connaissances récupérées, en escaladant selon le risque plutôt qu'en suivant des scénarios figés." }, { "q": "Pourquoi conserver une intervention humaine ?", "a": "Parce que certaines actions sont irréversibles ou réglementées. Une étape de validation basée sur le risque permet de maintenir la responsabilité humaine pour les étapes à fort impact, tout en automatisant la majorité des actions sûres." }, { "q": "Qu'est-ce qui le rend fiable ?", "a": "Un ancrage dans la recherche, des garde-fous sur les entrées et les sorties, et une observabilité qui vous permet d'évaluer chaque conversation et de détecter les régressions avant leur mise en production." } ] }, "de": { "name": "Kundenservice-Agent", "summary": "Eine Referenzarchitektur für einen Enterprise-Kundenservice-Agenten, der häufige Anfragen End-to-End löst – er antwortet auf Basis einer fundierten (grounded) Wissensdatenbank, agiert über Tools in CRM- und Ticketing-Systemen und eskaliert an einen Menschen, wenn das Vertrauen (Confidence) gering oder die Aktion folgenschwer ist. Sie kombiniert Retrieval für das Grounding mit risikobasierter menschlicher Freigabe zur Sicherheit und ist beobachtbar (observable), sodass jede Konversation evaluiert und verbessert werden kann.", "keyConcepts": [ "Grounding: Antworten stammen aus abgerufenem, zitierfähigem Wissen, nicht aus dem Speicher des Modells.", "Tool-Nutzung: Der Agent liest und schreibt über präzise beschriebene Tools in CRM- und Ticketing-Systeme.", "Risikobasierte Eskalation: Aktionen mit geringer Konfidenz oder hoher Tragweite werden an eine menschliche Kontrollinstanz übergeben.", "Observability: Jeder Interaktionsschritt (Turn) wird aufgezeichnet (traced), damit das System evaluiert und verbessert werden kann." ], "definition": "Die Customer-Service-Agent-Architektur ist ein auf Grounding basierender, Tool-nutzender Konversations-Agent, der Kundenanfragen autonom innerhalb von Guardrails löst, risiko- und konfidenzbasiert an Menschen eskaliert und vollständiges Tracing zur Evaluierung bietet.", "architecture": [ "Im Zentrum steht ein Orchestrierungs-Loop, der die eingehende Anfrage klassifiziert, relevantes Wissen abruft, entscheidet, ob er antworten kann oder handeln muss, und entweder antwortet, ein Tool aufruft oder eskaliert. Das Routing leitet einfache FAQs über einen kostengünstigen Retrieval-and-Answer-Pfad und komplexe oder sensible Fälle über einen umfassenderen, sorgfältigeren Pfad.", "Grounding ist unverzichtbar: Der Agent antwortet aus einem Retrieval-Layer über das Help Center und die Richtliniendokumente und zitiert seine Quellen. Wenn die Anfrage eine Aktion erfordert – wie eine Rückerstattung, eine Bestelländerung oder das Schließen eines Tickets –, bereitet der Agent die Aktion vor und leitet folgenschwere Aktionen vor der Ausführung über eine menschliche Freigabeinstanz.", "Übergreifende Layer machen das System sicher und verbesserungswürdig: Guardrails schwärzen PII (personenbezogene Daten) und blockieren richtlinienwidrige Antworten, ein semantischer Cache fängt wiederholte Fragen ab, um Kosten und Latenz zu senken, und ein Observability-Layer zeichnet jeden Turn auf, sodass Konversationen anhand eines Evaluierungssets bewertet werden können." ], "flow": [ "1. Intake: Die Benutzernachricht geht ein; PII wird erkannt und für das Logging geschwärzt.", "2. Route: Klassifizierung von Intent und Risiko – FAQ, Kontoaktion oder Eskalationskandidat.", "3. Retrieve: Abrufen von Grounding-Passagen aus der Wissensdatenbank (zuerst im Cache geprüft).", "4. Decide: Antworten basierend auf Grounding, Aufrufen eines CRM-/Ticketing-Tools oder Eskalieren.", "5. Gate: Folgenschwere Aktionen pausieren für die menschliche Freigabe; risikoarme Aktionen werden ausgeführt.", "6. Respond: Antworten mit Quellenangaben; Protokollieren des Traces und des Ergebnisses zur Evaluierung." ], "components": [ "Intent- & Risiko-Router", "Retrieval-Layer (RAG) mit Quellenangaben", "CRM- / Ticketing-Tools", "Menschliche Freigabeinstanz", "Guardrails & PII-Schwärzung", "Semantischer Cache", "Observability & Evaluierung" ], "referenceScenario": { "context": "Ein beispielhafter B2C-Support-Desk, der Bestell-, Abrechnungs- und Kontofragen über Chat und E-Mail bearbeitet.", "scenario": "Tier-1-Anfragen (Bestellstatus, Passwortzurücksetzung, Richtlinienfragen) werden vom Agenten gelöst; Rückerstattungen und Kontoänderungen werden vom Agenten entworfen und von einem Menschen freigegeben; Unklarheiten werden mit dem vollständigen Konversationskontext eskaliert.", "technology": "Orchestrierungs-Loop, RAG über das Help Center, Function-calling-Tools für das CRM, eine risikobasierte Freigabeinstanz und Konversations-Tracing.", "load": "Stoßartiger, stark auf die Geschäftszeiten konzentrierter Traffic mit einem Long Tail seltener Intents; eine kleine Anzahl von FAQs macht den Großteil des Volumens aus, das vom semantischen Cache abgefangen wird.", "results": "Referenzziel: Der Großteil des Tier-1-Volumens wird durch fundierte Antworten mit Quellenangaben abgefangen; folgenschwere Aktionen bleiben hinter einer menschlichen Freigabeinstanz; Kosten konzentrieren sich auf seltene, komplexe Fälle statt auf repetitive Aufgaben. Die genauen Zahlen hängen von Ihrem Traffic-Mix ab und sollten gemessen, nicht vorausgesetzt werden." }, "benefits": [ "Löst häufige Anfragen End-to-End, während risikoreiche Aktionen einer menschlichen Freigabe bedürfen.", "Fundierte Antworten mit Quellenangaben reduzieren Halluzinationen und stärken das Kundenvertrauen.", "Semantisches Caching und Routing konzentrieren die Ausgaben auf die Fälle, in denen sie tatsächlich benötigt werden.", "Vollständiges Tracing macht Qualität messbar und Regressionen erkennbar." ], "risks": [ "Nicht fundierte Antworten bei mangelhafter Retrieval-Qualität.", "Überautomatisierung von Aktionen, die einer menschlichen Freigabe bedürfen sollten.", "Abfluss von PII (personenbezogenen Daten), wenn Guardrails unvollständig sind.", "Freigabe-Engpässe, wenn zu viele Aktionen blockiert werden." ], "failureModes": [ "Das Retrieval schlägt fehl oder liefert veraltete Richtlinien, sodass der Agent zwar selbstsicher, aber falsch antwortet.", "Tool-Fehler (CRM-Timeouts, Schema-Drift) führen dazu, dass Aktionen ohne Wiederherstellungsmöglichkeit nur halb ausgeführt werden.", "Eskalationsüberlastung, wenn der Router zu viele Fälle an Menschen weiterleitet, was den Nutzen der Automatisierung zunichte macht.", "Fehlerhafte Cache-Treffer (False Hits) liefern den Kontext eines vorherigen Kunden oder eine veraltete Antwort." ], "lessons": [ "Zuerst Grounding: Investieren Sie in die Retrieval-Qualität, bevor Sie die Autonomie ausbauen – die meisten falschen Antworten sind auf Retrieval-Fehler zurückzuführen.", "Freigabe nach Risiko, nicht standardmäßig; behalten Sie die menschliche Freigabe für irreversible oder regulierte Aktionen vor.", "Grenzen Sie den Cache pro Kunde/Kontext ab und validieren Sie Treffer, da sonst falsche Antworten durchsickern.", "Instrumentieren Sie von Tag eins an; Sie können nicht verbessern, was Sie nicht aufzeichnen (tracen) können." ], "kpis": [ { "metric": "Containment- / Deflection-Rate", "note": "Anteil der Konversationen, die ohne menschliches Zutun gelöst wurden; die wichtigste Wertmetrik – aber nur in Kombination mit dem CSAT aussagekräftig." }, { "metric": "Genauigkeit fundierter Antworten (Grounded-answer accuracy)", "note": "Wie oft Antworten korrekt und durch eine Quellenangabe belegt sind, gemessen an einem Evaluierungsset." }, { "metric": "Eskalationsrate & -qualität", "note": "Anteil der an Menschen eskalierten Fälle und ob diese Eskalationen berechtigt waren; eine zu hohe Rate schmälert den Nutzen der Automatisierung, eine zu niedrige birgt das Risiko schlechter Ergebnisse." }, { "metric": "Kosten pro gelöster Konversation", "note": "Gesamtzahl der Token, Tools und Cache-Effekte pro Lösung; Routing und Caching sollten diese Kosten auf dem Standardpfad niedrig halten." }, { "metric": "CSAT / Lösungszeit", "note": "Kundenzufriedenheit und Zeit bis zur Lösung; schützt davor, die Deflection-Rate auf Kosten der Customer Experience zu optimieren." } ], "scaling": [ "Das Volumen skaliert mit dem zustandslosen Orchestrierungs-Loop; der Vector Store und die Tool-Backends bilden die tatsächlichen Kapazitätsgrenzen.", "Der semantische Cache dämpft den Kostenanstieg bei zunehmenden wiederholten Fragen, sodass die Stückkosten bei Skalierung auf dem Standardpfad sinken.", "Die menschliche Freigabe ist der Flaschenhals, der nicht linear skaliert – halten Sie die Menge der zu prüfenden Aktionen klein und vorsortiert.", "Die Kosten werden von den seltenen, komplexen Konversationen dominiert, nicht von der Mehrheit der im Cache gespeicherten FAQs." ], "examples": [ "Eine Frage zum Bestellstatus, die sofort aus dem Cache mit einer Quellenangabe beantwortet wird.", "Eine Rückerstattung, die der Agent entwirft und ein Mensch freigibt, bevor sie veranlasst wird.", "Ein unklarer Abrechnungsstreit, der mit dem vollständigen Konversationskontext an einen Mitarbeiter eskaliert wird." ], "faqs": [ { "q": "Wie unterscheidet sich dies von einem Chatbot?", "a": "Ein Chatbot antwortet nur; diese Architektur handelt auch – sie nutzt Tools, um in Enterprise-Systemen zu lesen und zu schreiben – und sie stützt ihre Antworten auf abgerufenes Wissen (Grounding), wobei sie risikobasiert eskaliert, anstatt starren Skripten zu folgen." }, { "q": "Warum sollte überhaupt ein Mensch in den Prozess eingebunden bleiben (Human-in-the-Loop)?", "a": "Weil manche Aktionen unumkehrbar oder reguliert sind. Eine risikobasierte Freigabeinstanz stellt sicher, dass die Verantwortung für folgenschwere Schritte beim Menschen verbleibt, während die sichere Mehrheit automatisiert wird." }, { "q": "Was macht das System zuverlässig?", "a": "Grounding in Retrieval, Guardrails für Inputs und Outputs sowie Observability, mit der Sie jede Konversation evaluieren und Regressionen vor dem Release abfangen können." } ] }, "ja": { "name": "カスタマーサービスエージェント", "summary": "一般的なリクエストをエンドツーエンドで解決する、エンタープライズ向けカスタマーサービスエージェントのリファレンスアーキテクチャです。グラウンディングされたナレッジベースに基づいて回答し、ツールを介してCRMやチケット管理システムでアクションを実行し、確信度が低い場合や影響の大きいアクションの場合は人間にエスカレーションします。安全性のためにグラウンディング用の検索とリスクベースの人間による承認を組み合わせ、すべての会話を評価・改善できるようにオブザーバビリティ（可観測性）を確保しています。", "keyConcepts": [ "グラウンディング：回答はモデルの記憶からではなく、検索された引用可能なナレッジから生成されます。", "ツールの利用：エージェントは、明確に定義されたツールを介してCRMやチケット管理システムへの読み書きを行います。", "リスクベースのエスカレーション：確信度が低いアクションや影響の大きいアクションは、人間による承認ゲートに送られます。", "オブザーバビリティ：すべてのやり取り（ターン）がトレースされ、システムの評価と改善が可能になります。" ], "definition": "カスタマーサービスエージェントのアーキテクチャは、ガードレールの範囲内で自律的に顧客のリクエストを解決する、グラウンディングとツール利用を備えた対話型エージェントです。リスクと確信度に基づいて人間にエスカレーションし、評価のための完全なトレース機能を備えています。", "architecture": [ "その中核となるのは、受信したリクエストを分類し、関連するナレッジを検索し、回答可能かアクションが必要かを判断して、応答、ツールの呼び出し、またはエスカレーションを行うオーケストレーションループです。ルーティングにより、シンプルなFAQは低コストな「検索と回答」のパスに送られ、複雑または機密性の高いケースは、より高度で慎重なパスに送られます。", "グラウンディングは必須要件です。エージェントはヘルプセンターやポリシー文書に対する検索レイヤーから回答を生成し、その情報源を引用します。返金処理、注文変更、チケットのクローズなどのアクションがリクエストに必要な場合、エージェントはアクションを準備し、影響の大きいものは実行前に人間による承認ゲートにルーティングします。", "横断的なレイヤーにより、安全性と改善可能性が確保されます。ガードレールがPII（個人特定情報）を墨消しし、ポリシー違反の応答をブロックします。セマンティックキャッシュが重複する質問を吸収してコストとレイテンシーを削減し、オブザーバビリティレイヤーがすべてのやり取りをトレースして、評価セットに照らし合わせて会話をスコアリングできるようにします。" ], "flow": [ "1. 受付：ユーザーメッセージが到着します。PIIが検出され、ログ記録のために墨消しされます。", "2. ルーティング：インテント（意図）とリスクを分類します（FAQ、アカウント操作、またはエスカレーション候補）。", "3. 検索：ナレッジベースからグラウンディング用の文章をプルします（最初にキャッシュがチェックされます）。", "4. 判断：グラウンディングに基づいて回答するか、CRM/チケット管理ツールを呼び出すか、あるいはエスカレーションします。", "5. ゲート：影響の大きいアクションは人間による承認のために一時停止し、影響の小さいアクションは実行されます。", "6. 応答：引用付きで返答します。評価のためにトレースと結果をログに記録します。" ], "components": [ "インテント＆リスクルーター", "引用付き検索レイヤー（RAG）", "CRM / チケット管理ツール", "人間による承認ゲート", "ガードレール＆PIIの墨消し", "セマンティックキャッシュ", "オブザーバビリティ＆評価" ], "referenceScenario": { "context": "チャットやメールを通じて、注文、請求、アカウントに関する質問に対応する、B2Cサポートデスクの図解例。", "scenario": "ティア1のリクエスト（注文ステータス、パスワードリセット、ポリシーに関する質問）はエージェントによって解決されます。返金やアカウント変更はエージェントが下書きを作成し、人間が承認します。曖昧なものはすべて、完全なコンテキストを添えてエスカレーションされます。", "technology": "オーケストレーションループ、ヘルプセンターに対するRAG、CRMへのファンクションコーリングツール、リスクベースの承認ゲート、および会話のトレース。", "load": "営業時間内に集中するバースト性の高いトラフィックと、まれなインテントのロングテール。少数のFAQがボリュームの大半を占め、これをセマンティックキャッシュが吸収します。", "results": "リファレンスターゲット：ティア1のボリュームの大部分を、グラウンディングされ引用を伴う回答によって回避（デフレクション）します。影響の大きいアクションは人間によるゲートの後方に維持し、コストを反復的なケースではなく、まれで複雑なケースに集中させます。数値はトラフィックの構成比に依存するため、想定するのではなく測定する必要があります。" }, "benefits": [ "リスクのあるアクションを人間によるゲートで保護しつつ、一般的なリクエストをエンドツーエンドで解決します。", "グラウンディングされ引用を伴う回答により、ハルシネーションを減らし、顧客の信頼を築きます。", "セマンティックキャッシュとルーティングにより、対応が必要なケースに支出を集中させます。", "完全なトレースにより品質を測定可能にし、デグレード（先祖返り）を検知できるようにします。" ], "risks": [ "検索品質が低い場合、グラウンディングされていない回答が生成されるリスク。", "人間によるゲートにとどめるべきアクションの過剰な自動化。", "ガードレールが不完全な場合におけるPIIの漏洩。", "ゲートされるアクションが多すぎる場合における承認のボトルネック。" ], "failureModes": [ "検索漏れが発生するか、古いポリシーが返されることで、エージェントが自信ありげに誤った回答をしてしまう。", "ツールエラー（CRMのタイムアウト、スキーマの乖離など）により、アクションが回復不能なまま中途半端に適用された状態になる。", "ルーターが人間に多くを送りすぎることでエスカレーションが過負荷になり、自動化の効果が損なわれる。", "キャッシュの誤ヒットにより、以前の顧客のコンテキストや古い回答が返されてしまう。" ], "lessons": [ "まずグラウンディングを：自律性を拡大する前に検索品質に投資してください。誤った回答のほとんどは検索の失敗に起因します。", "デフォルトではなくリスクに基づいてゲートを設定してください。人間による承認は、取り消し不可能なアクションや規制対象のアクションに限定します。", "キャッシュのスコープを顧客またはコンテキストごとに設定し、ヒット内容を検証してください。そうしないと、誤った回答が漏洩する原因になります。", "初日からインストルメンテーション（計測機能の実装）を行ってください。トレースできないものを改善することはできません。" ], "kpis": [ { "metric": "解決率 / 回避率（デフレクション率）", "note": "人間を介さずに解決された会話の割合。主要な価値指標ですが、CSAT（顧客満足度）と併せて評価して初めて意味を持ちます。" }, { "metric": "グラウンディングされた回答の正確性", "note": "回答が正確であり、かつ引用によって裏付けられている頻度。評価セットに照らし合わせて測定します。" }, { "metric": "エスカレーション率＆品質", "note": "人間にエスカレーションされた割合と、それらのエスカレーションが妥当であったかどうか。高すぎると自動化が無駄になり、低すぎると悪い結果を招くリスクがあります。" }, { "metric": "解決された会話あたりのコスト", "note": "解決あたりの総トークン数、ツール、およびキャッシュの効果。ルーティングとキャッシュにより、一般的なパスではこれを低く抑える必要があります。" }, { "metric": "CSAT / 解決時間", "note": "顧客満足度および解決までの時間。顧客体験を犠牲にして回避率（デフレクション）を最適化してしまうのを防ぎます。" } ], "scaling": [ "ボリュームはステートレスなオーケストレーションループによってスケールしますが、実際の容量制限となるのはベクトルストアとツールのバックエンドです。", "重複する質問が増えてもセマンティックキャッシュがコストを平準化するため、一般的なパスではスケールに応じてユニットコストが低下します。", "人間による承認は線形にスケールしないボトルネックです。ゲート対象となるセットを小さく保ち、優先順位付け（トリアージ）を行ってください。", "コストの大部分を占めるのは、キャッシュされた多数 of FAQではなく、まれで複雑な会話です。" ], "examples": [ "注文ステータスに関する質問に対し、キャッシュから引用付きで即座に回答する。", "エージェントが返金の下書きを作成し、発行前に人間が承認する。", "曖昧な請求に関する紛争を、会話の完全なコンテキストを添付して人間のエージェントにエスカレーションする。" ], "faqs": [ { "q": "これはチャットボットとどう違うのですか？", "a": "チャットボットは回答するだけですが、このアーキテクチャはアクションも実行します。ツールを使用してエンタープライズシステムへの読み書きを行い、検索されたナレッジに基づいて回答をグラウンディングし、固定のスクリプトに従うのではなくリスクに基づいてエスカレーションします。" }, { "q": "なぜ人間を関与させ続ける（Human-in-the-loop）必要があるのですか？", "a": "一部のアクションは取り消し不可能であったり、規制対象であったりするためです。リスクベースの承認ゲートを設けることで、安全な大部分の自動化を進めつつ、影響の大きいステップにおける説明責任を人間にとどめることができます。" }, { "q": "何が信頼性を担保するのですか？", "a": "検索によるグラウンディング（根拠付け）、入力と出力に対するガードレール、そしてすべての会話を評価して本番リリース前にデグレード（退行）を検知できるオブザーバビリティです。" } ] }, "zh": { "name": "客户服务智能体", "summary": "企业级客户服务智能体的参考架构，可端到端地解决常见请求——基于可靠的知识库进行回答，通过工具在 CRM 和工单系统中执行操作，并在置信度较低或操作影响重大时升级给人工处理。它将用于知识对齐（grounding）的检索与基于风险的人工审批相结合以确保安全，并具备可观测性，以便对每次对话进行评估和改进。", "keyConcepts": [ "知识对齐（Grounding）：回答来自检索到的、可引用的知识，而非模型的记忆。", "工具使用：智能体通过描述清晰的工具对 CRM/工单系统进行读写操作。", "基于风险的升级：置信度较低或高影响的操作将流转至人工审核关卡。", "可观测性：对每一次交互进行追踪，以便对系统进行评估和改进。" ], "definition": "客户服务智能体架构是一种基于知识对齐、使用工具的对话式智能体，它能在安全护栏内自主解决客户请求，根据风险和置信度升级给人工处理，并提供完整的追踪以供评估。", "architecture": [ "其核心是一个编排循环，用于对传入的请求进行分类、检索相关知识、决定是可以直接回答还是必须执行操作，然后做出响应、调用工具或进行升级。路由机制会将简单的常见问题解答（FAQ）分流到低成本的检索与回答路径，而将复杂或敏感的案例分流到更丰富、更谨慎的路径。", "知识对齐（Grounding）是必不可少的：智能体基于帮助中心和政策文档的检索层进行回答，并引用其来源。当请求需要执行操作（如退款、修改订单、关闭工单）时，智能体会准备好该操作，并在执行前将高影响的操作路由到人工审批关卡。", "横切关注层使其具备安全性和可改进性：安全护栏可脱敏个人身份信息（PII）并拦截不符合政策的响应；语义缓存可吸收重复问题以降低成本 and 延迟；可观测性层可追踪每一次交互，以便对照评估集对对话进行评分。" ], "flow": [ "1. 接收：用户消息到达；检测并脱敏个人身份信息（PII）以进行日志记录。", "2. 路由：对意图和风险进行分类——常见问题解答（FAQ）、账户操作或待升级候选件。", "3. 检索：从知识库中提取用于对齐的段落（首先检查缓存）。", "4. 决策：基于对齐的知识进行回答、调用 CRM/工单工具，或进行升级。", "5. 关卡：高影响操作暂停以等待人工审批；低影响操作直接执行。", "6. 响应：附带引用进行回复；记录追踪信息 and 结果以供评估。" ], "components": [ "意图与风险路由器", "带引用的检索层（RAG）", "CRM / 工单工具", "人工审批关卡", "安全护栏与 PII 脱敏", "语义缓存", "可观测性与评估" ], "referenceScenario": { "context": "一个典型的 B2C 支持服务台，通过聊天和电子邮件处理订单、账单和账户问题。", "scenario": "一线请求（订单状态、密码重置、政策咨询）由智能体解决；退款和账户变更由智能体起草并由人工审批；任何含糊不清的问题都会附带完整的上下文升级给人工处理。", "technology": "编排循环、基于帮助中心的 RAG、调用 CRM 的函数调用工具、基于风险的审批关卡以及对话追踪。", "load": "具有突发性且集中在工作时间的流量，伴有长尾的罕见意图；少数常见问题解答（FAQ）占了大部分流量，这些流量由语义缓存吸收。", "results": "参考目标：大部分一线流量通过基于知识对齐且附带引用的回答进行分流；高影响操作保留在人工关卡之后；成本集中在罕见、复杂的案例上，而非重复性的案例。具体数值取决于您的流量组合，应进行实际测量，而非主观假设。" }, "benefits": [ "端到端解决常见请求，同时将高风险操作保留在人工审批关卡之后。", "基于知识对齐且附带引用的回答可减少幻觉，建立客户信任。", "语义缓存和路由机制可将开销集中在真正需要的案例上。", "完整的追踪使质量可衡量，并能捕获回归问题。" ], "risks": [ "如果检索质量差，会导致回答缺乏知识对齐。", "过度自动化本应保留在人工审批关卡之后的操作。", "如果安全护栏不完整，会导致个人身份信息（PII）泄露。", "如果设置审批关卡的操作过多，会导致审批瓶颈。" ], "failureModes": [ "检索遗漏或返回了过时的政策，导致智能体给出了看似笃定但实际上错误的回答。", "工具错误（CRM 超时、Schema 漂移）导致操作处于半应用状态且无法恢复。", "当路由器将过多请求发送给人工时，会导致升级过载，从而使自动化失去意义。", "缓存错误命中返回了前一个客户的上下文或过时的回答。" ], "lessons": [ "对齐优先：在扩大自主权之前，先投入精力提升检索质量——大多数错误的回答都是检索失败导致的。", "按风险设置关卡，而非默认设置；将人工审批保留给不可逆或受监管的操作。", "按客户/上下文限制缓存范围并验证命中情况，否则会泄露错误的回答。", "从第一天起就进行插桩；无法追踪就无法改进。" ], "kpis": [ { "metric": "自助解决率 / 分流率", "note": "无需人工介入即可解决的对话比例；这是核心价值指标——但只有与客户满意度（CSAT）结合时才有意义。" }, { "metric": "对齐回答准确率", "note": "对照评估集衡量，回答正确且有引用支持的频率。" }, { "metric": "升级率与升级质量", "note": "升级到人工处理的比例以及这些升级是否合理；比例过高会浪费自动化资源，过低则可能导致不良后果。" }, { "metric": "单次解决对话的成本", "note": "每次解决所需的总 Token 数、工具调用和缓存效果；路由和缓存机制应使常规路径上的这一成本保持在较低水平。" }, { "metric": "CSAT / 解决时间", "note": "客户满意度和解决时间；防止以牺牲客户体验为代价来优化分流率。" } ], "scaling": [ "业务量随无状态编排循环进行扩展；向量存储和工具后端才是真正的容量限制瓶颈。", "随着重复问题的增加，语义缓存可以平抑成本，因此在常规路径上，单位成本会随着规模的扩大而下降。", "人工审批是无法线性扩展的瓶颈——应保持需要审批的操作集规模较小并做好分类。", "成本主要由罕见、复杂的对话决定，而非占大多数的已缓存常见问题解答（FAQ）。" ], "examples": [ "一个订单状态问题，通过缓存立即回答并附带引用。", "由智能体起草并在发放前由人工审批的退款。", "一个含糊不清的账单争议，附带完整的对话上下文升级给人工客服处理。" ], "faqs": [ { "q": "这与聊天机器人有什么不同？", "a": "聊天机器人只负责回答；而该架构还能执行操作——它使用工具对企业系统进行读写——并且它将回答与检索到的知识进行对齐，根据风险进行升级，而不是遵循固定的脚本。" }, { "q": "为什么还要保留人工参与？", "a": "因为某些操作是不可逆的或受监管的。基于风险的审批关卡可确保高影响步骤的责任落实到人，同时实现绝大多数安全操作的自动化。" }, { "q": "是什么使其具有可靠性？", "a": "基于检索的真实性锚定（Grounding）、针对输入和输出的安全护栏，以及能够让您评估每一次对话并在发布前捕获退化问题的可观测性。" } ] } } }, { "id": "ARCH-002", "slug": "enterprise-knowledge-assistant", "category": "knowledge", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/architectures/enterprise-knowledge-assistant", "api": "https://santismm.com/api/architectures/enterprise-knowledge-assistant", "canonical_url": "https://santismm.com/en/architectures/enterprise-knowledge-assistant", "api_url": "https://santismm.com/api/architectures/enterprise-knowledge-assistant", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "high", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "RAG (retrieval-augmented generation)", "Embeddings + vector store", "Hybrid search & reranking", "Document-level access control", "Evaluation harness", "Observability (LangSmith / Langfuse)" ], "patterns": [ "routing", "semantic-caching", "evaluator-optimizer", "prompt-chaining" ], "knowledge": [ "enterprise-rag", "embeddings", "context-engineering", "guardrails", "agentic-evaluation", "ai-governance" ], "references": [ { "title": "Lewis et al. — Retrieval-Augmented Generation (2020)", "url": "https://arxiv.org/abs/2005.11401" }, { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "related": [ "customer-service-agent" ], "locales": { "en": { "name": "Enterprise Knowledge Assistant", "summary": "A reference architecture for an internal knowledge assistant that answers employee questions from the company's own documents — wikis, policies, tickets, code — with citations and respecting each user's access permissions. It combines hybrid retrieval and reranking for grounding, permission-aware filtering for security, and an evaluation harness so answer quality is measured rather than assumed. The hard parts are not the model; they are retrieval quality, access control and evaluation.", "keyConcepts": [ "Permission-aware retrieval: a user only ever retrieves documents they are allowed to see.", "Hybrid search + reranking: combine keyword and vector search, then rerank for precision.", "Citations: every answer links back to its source passages for verification.", "Evaluation: answer quality is scored against a curated set, continuously." ], "definition": "The enterprise knowledge assistant architecture is a permission-aware RAG system that answers employee questions from internal documents with citations, scoped to each user's access rights and continuously evaluated for quality.", "architecture": [ "Content from many internal sources is ingested, chunked and embedded into a vector store, with each chunk tagged by its source document's access-control metadata. At query time the assistant routes the question, runs hybrid retrieval (keyword + vector) filtered to the user's permissions, reranks the candidates, and synthesizes a cited answer from the top passages.", "Security is structural, not bolted on: the access-control filter is applied during retrieval so the model never even sees documents the user cannot access. A semantic cache serves repeated questions cheaply, and guardrails keep answers within policy and flag low-confidence cases.", "Quality is governed by measurement: an evaluation harness scores answers for groundedness, correctness and citation accuracy against a curated set, and an optional evaluator-optimizer loop revises weak answers before they reach the user. Observability traces every query so failures can be diagnosed and fed back into the evals." ], "flow": [ "1. Ingest (offline): chunk and embed documents; tag each chunk with access-control metadata.", "2. Route: classify the question and pick the retrieval strategy.", "3. Retrieve: hybrid search filtered to the user's permissions (cache-checked first).", "4. Rerank: reorder candidates for precision; keep the top passages.", "5. Synthesize: generate a cited answer; optionally revise it via an evaluator loop.", "6. Return & log: deliver answer with citations; trace and score for evaluation." ], "components": [ "Ingestion & chunking pipeline", "Embeddings + vector store", "Permission-aware retrieval filter", "Hybrid search & reranker", "Answer synthesis with citations", "Semantic cache", "Evaluation harness & observability" ], "referenceScenario": { "context": "An illustrative internal assistant over a company's wiki, HR and IT policies, and engineering docs.", "scenario": "Employees ask natural-language questions ('how do I expense travel?', 'what's our on-call policy?'); the assistant answers with citations, never surfacing documents the asker cannot access, and says 'I don't know' rather than guessing when retrieval is weak.", "technology": "Ingestion pipeline, embeddings + vector store with ACL metadata, hybrid retrieval and reranking, an evaluation harness, and query tracing.", "load": "Steady internal traffic with strong query overlap (a few policies drive most questions), so the cache hit rate is high and embeddings dominate the offline cost.", "results": "Reference target: grounded, cited answers with no access-control leaks, and a measurable groundedness score that improves as retrieval is tuned. Treat all figures as things to measure on your corpus, not guarantees." }, "benefits": [ "Turns scattered internal knowledge into instant, cited answers.", "Permission-aware retrieval prevents access-control leaks by construction.", "Citations make answers verifiable and build user trust.", "An evaluation harness makes quality measurable and improvements demonstrable." ], "risks": [ "Access-control leaks if permissions are not enforced at retrieval time.", "Stale answers when the document corpus changes faster than re-indexing.", "Confident hallucination when retrieval is weak and the model fills the gap.", "Poor chunking that fragments meaning and degrades retrieval." ], "failureModes": [ "Permission bypass: a chunk inherits the wrong ACL and surfaces in a user's results.", "Retrieval gaps: the right document exists but chunking or embeddings miss it.", "Staleness: an answer cites a superseded policy because re-indexing lagged.", "Citation drift: the cited passage doesn't actually support the generated claim." ], "lessons": [ "Enforce access control inside retrieval, not after generation — filtering the prompt is too late.", "Most quality gains come from retrieval (chunking, hybrid search, reranking), not from a bigger model.", "Make 'I don't know' a first-class answer; a wrong confident answer is worse than an abstention.", "Stand up evaluation before scaling; without it, every change is a guess." ], "kpis": [ { "metric": "Groundedness", "note": "Share of answers fully supported by the cited passages; the core quality metric for a RAG assistant." }, { "metric": "Retrieval recall@k", "note": "How often the right passage is in the top-k retrieved; most answer errors trace back to this." }, { "metric": "Access-control leak rate", "note": "Any answer surfacing a document the user couldn't access — the metric that must stay at zero." }, { "metric": "Cache hit rate & cost per query", "note": "Repeat-question coverage and unit cost; high overlap should make most queries cheap." }, { "metric": "Abstention quality", "note": "How often the assistant correctly says 'I don't know' instead of hallucinating on weak retrieval." } ], "scaling": [ "Offline embedding and indexing dominate ingestion cost and grow with corpus size and update frequency.", "Query-time cost is mostly retrieval + generation; reranking adds latency you trade for precision.", "The cache flattens cost as query overlap rises, so unit cost falls with adoption.", "Re-indexing cadence is the real scaling tension: fresher answers cost more compute." ], "examples": [ "An employee asking the travel-expense policy and getting a cited, up-to-date answer.", "A question about a restricted project correctly returning nothing for an unauthorized user.", "A weak-retrieval query answered with 'I don't have a confident source for that' instead of a guess." ], "faqs": [ { "q": "Isn't this just RAG?", "a": "RAG is the core, but the architecture is defined by what makes it enterprise-safe: permission-aware retrieval, citations, an evaluation harness and observability. Those are the parts that decide whether it can be trusted." }, { "q": "Why enforce permissions during retrieval?", "a": "So the model never sees documents the user can't access. Filtering after generation is too late — the content could already have leaked into the answer." }, { "q": "How do you keep answers from hallucinating?", "a": "Ground every answer in retrieved passages with citations, measure groundedness against an eval set, and let the assistant abstain when retrieval is weak rather than fill the gap." } ] }, "es": { "name": "Asistente de Conocimiento Empresarial", "summary": "Una arquitectura de referencia para un asistente de conocimiento interno que responde preguntas de los empleados desde los propios documentos de la empresa —wikis, políticas, tickets, código— con citas y respetando los permisos de acceso de cada usuario. Combina recuperación híbrida y reranking para fundamentar, filtrado por permisos para la seguridad, y un arnés de evaluación para que la calidad se mida en vez de asumirse. Lo difícil no es el modelo; es la calidad de la recuperación, el control de acceso y la evaluación.", "keyConcepts": [ "Recuperación con permisos: un usuario solo recupera documentos que tiene permitido ver.", "Búsqueda híbrida + reranking: combinar búsqueda por palabras clave y vectorial, y luego reordenar por precisión.", "Citas: cada respuesta enlaza a sus pasajes fuente para verificación.", "Evaluación: la calidad de las respuestas se puntúa contra un conjunto curado, de forma continua." ], "definition": "La arquitectura de asistente de conocimiento empresarial es un sistema RAG con conciencia de permisos que responde preguntas de empleados desde documentos internos con citas, acotado a los derechos de acceso de cada usuario y evaluado de forma continua.", "architecture": [ "El contenido de muchas fuentes internas se ingiere, trocea e incrusta en un almacén vectorial, con cada fragmento etiquetado por los metadatos de control de acceso de su documento de origen. En la consulta, el asistente enruta la pregunta, ejecuta recuperación híbrida (palabras clave + vectorial) filtrada a los permisos del usuario, reordena los candidatos y sintetiza una respuesta citada a partir de los mejores pasajes.", "La seguridad es estructural, no añadida: el filtro de control de acceso se aplica durante la recuperación, así que el modelo nunca ve documentos a los que el usuario no puede acceder. Una caché semántica sirve preguntas repetidas de forma barata, y los guardarraíles mantienen las respuestas dentro de política y marcan los casos de baja confianza.", "La calidad se gobierna con medición: un arnés de evaluación puntúa las respuestas por fundamentación, corrección y precisión de citas contra un conjunto curado, y un bucle opcional evaluador-optimizador revisa las respuestas débiles antes de que lleguen al usuario. La observabilidad traza cada consulta para diagnosticar fallos y retroalimentar las evaluaciones." ], "flow": [ "1. Ingesta (offline): trocear e incrustar documentos; etiquetar cada fragmento con metadatos de control de acceso.", "2. Enrutar: clasificar la pregunta y elegir la estrategia de recuperación.", "3. Recuperar: búsqueda híbrida filtrada a los permisos del usuario (con caché comprobada primero).", "4. Reordenar: reordenar candidatos por precisión; quedarse con los mejores pasajes.", "5. Sintetizar: generar una respuesta citada; opcionalmente revisarla con un bucle evaluador.", "6. Devolver y registrar: entregar la respuesta con citas; trazar y puntuar para evaluación." ], "components": [ "Pipeline de ingesta y troceado", "Embeddings + almacén vectorial", "Filtro de recuperación con permisos", "Búsqueda híbrida y reranker", "Síntesis de respuesta con citas", "Caché semántica", "Arnés de evaluación y observabilidad" ], "referenceScenario": { "context": "Un asistente interno ilustrativo sobre la wiki de una empresa, las políticas de RRHH e IT, y la documentación de ingeniería.", "scenario": "Los empleados hacen preguntas en lenguaje natural ('¿cómo reporto gastos de viaje?', '¿cuál es la política de guardias?'); el asistente responde con citas, sin mostrar nunca documentos que quien pregunta no puede ver, y dice 'no lo sé' en vez de adivinar cuando la recuperación es débil.", "technology": "Pipeline de ingesta, embeddings + almacén vectorial con metadatos de ACL, recuperación híbrida y reranking, un arnés de evaluación y trazado de consultas.", "load": "Tráfico interno estable con fuerte solapamiento de consultas (unas pocas políticas generan la mayoría de preguntas), así que la tasa de aciertos de caché es alta y los embeddings dominan el coste offline.", "results": "Objetivo de referencia: respuestas fundamentadas y citadas sin fugas de control de acceso, y una puntuación de fundamentación medible que mejora al afinar la recuperación. Trata todas las cifras como algo a medir en tu corpus, no como garantías." }, "benefits": [ "Convierte el conocimiento interno disperso en respuestas instantáneas y citadas.", "La recuperación con permisos previene fugas de control de acceso por construcción.", "Las citas hacen las respuestas verificables y generan confianza.", "Un arnés de evaluación hace la calidad medible y las mejoras demostrables." ], "risks": [ "Fugas de control de acceso si los permisos no se aplican en la recuperación.", "Respuestas obsoletas cuando el corpus cambia más rápido que la reindexación.", "Alucinación confiada cuando la recuperación es débil y el modelo rellena el hueco.", "Troceado deficiente que fragmenta el significado y degrada la recuperación." ], "failureModes": [ "Salto de permisos: un fragmento hereda la ACL equivocada y aparece en los resultados de un usuario.", "Huecos de recuperación: el documento correcto existe pero el troceado o los embeddings no lo encuentran.", "Obsolescencia: una respuesta cita una política superada porque la reindexación se retrasó.", "Deriva de citas: el pasaje citado no respalda realmente la afirmación generada." ], "lessons": [ "Aplica el control de acceso dentro de la recuperación, no tras la generación; filtrar el prompt es demasiado tarde.", "La mayoría de las mejoras de calidad vienen de la recuperación (troceado, búsqueda híbrida, reranking), no de un modelo más grande.", "Haz de 'no lo sé' una respuesta de primera clase; una respuesta confiada y errónea es peor que una abstención.", "Monta la evaluación antes de escalar; sin ella, cada cambio es una conjetura." ], "kpis": [ { "metric": "Fundamentación", "note": "Proporción de respuestas totalmente respaldadas por los pasajes citados; la métrica de calidad central de un asistente RAG." }, { "metric": "Recall@k de recuperación", "note": "Con qué frecuencia el pasaje correcto está en los top-k recuperados; la mayoría de errores de respuesta se remontan a esto." }, { "metric": "Tasa de fuga de control de acceso", "note": "Cualquier respuesta que muestre un documento al que el usuario no podía acceder; la métrica que debe quedarse en cero." }, { "metric": "Tasa de aciertos de caché y coste por consulta", "note": "Cobertura de preguntas repetidas y coste unitario; un alto solapamiento debería abaratar la mayoría de consultas." }, { "metric": "Calidad de abstención", "note": "Con qué frecuencia el asistente dice correctamente 'no lo sé' en vez de alucinar ante una recuperación débil." } ], "scaling": [ "La incrustación e indexación offline dominan el coste de ingesta y crecen con el tamaño del corpus y la frecuencia de actualización.", "El coste en consulta es sobre todo recuperación + generación; el reranking añade latencia que cambias por precisión.", "La caché aplana el coste a medida que sube el solapamiento de consultas, así que el coste unitario baja con la adopción.", "La cadencia de reindexación es la verdadera tensión de escala: respuestas más frescas cuestan más cómputo." ], "examples": [ "Un empleado preguntando la política de gastos de viaje y obteniendo una respuesta citada y actualizada.", "Una pregunta sobre un proyecto restringido devolviendo correctamente nada para un usuario no autorizado.", "Una consulta con recuperación débil respondida con 'no tengo una fuente fiable para eso' en vez de adivinar." ], "faqs": [ { "q": "¿Esto no es solo RAG?", "a": "RAG es el núcleo, pero la arquitectura la define lo que la hace segura para la empresa: recuperación con permisos, citas, un arnés de evaluación y observabilidad. Esas son las partes que deciden si se puede confiar en ella." }, { "q": "¿Por qué aplicar permisos durante la recuperación?", "a": "Para que el modelo nunca vea documentos a los que el usuario no puede acceder. Filtrar tras la generación es demasiado tarde: el contenido ya podría haberse filtrado en la respuesta." }, { "q": "¿Cómo se evita que las respuestas alucinen?", "a": "Fundamenta cada respuesta en pasajes recuperados con citas, mide la fundamentación contra un conjunto de evaluación, y deja que el asistente se abstenga cuando la recuperación es débil en vez de rellenar el hueco." } ] }, "pt": { "name": "Assistente de Conhecimento Empresarial", "summary": "Uma arquitetura de referência para um assistente de conhecimento interno que responde perguntas dos funcionários a partir dos próprios documentos da empresa —wikis, políticas, tickets, código— com citações e respeitando as permissões de acesso de cada usuário. Combina recuperação híbrida e reranking para fundamentar, filtragem por permissões para segurança, e um harness de avaliação para que a qualidade seja medida em vez de assumida. O difícil não é o modelo; é a qualidade da recuperação, o controle de acesso e a avaliação.", "keyConcepts": [ "Recuperação com permissões: um usuário só recupera documentos que tem permissão de ver.", "Busca híbrida + reranking: combinar busca por palavras-chave e vetorial, e então reordenar por precisão.", "Citações: cada resposta liga aos seus trechos fonte para verificação.", "Avaliação: a qualidade das respostas é pontuada contra um conjunto curado, continuamente." ], "definition": "A arquitetura de assistente de conhecimento empresarial é um sistema RAG com consciência de permissões que responde perguntas de funcionários a partir de documentos internos com citações, restrito aos direitos de acesso de cada usuário e avaliado continuamente.", "architecture": [ "O conteúdo de muitas fontes internas é ingerido, fragmentado e incorporado em um armazenamento vetorial, com cada fragmento marcado pelos metadados de controle de acesso do seu documento de origem. Na consulta, o assistente roteia a pergunta, executa recuperação híbrida (palavras-chave + vetorial) filtrada às permissões do usuário, reordena os candidatos e sintetiza uma resposta citada a partir dos melhores trechos.", "A segurança é estrutural, não acoplada: o filtro de controle de acesso é aplicado durante a recuperação, então o modelo nunca vê documentos aos quais o usuário não pode acessar. Um cache semântico serve perguntas repetidas de forma barata, e os guard-rails mantêm as respostas dentro da política e sinalizam os casos de baixa confiança.", "A qualidade é governada por medição: um harness de avaliação pontua as respostas por fundamentação, correção e precisão de citações contra um conjunto curado, e um loop opcional avaliador-otimizador revisa as respostas fracas antes de chegarem ao usuário. A observabilidade rastreia cada consulta para diagnosticar falhas e realimentar as avaliações." ], "flow": [ "1. Ingestão (offline): fragmentar e incorporar documentos; marcar cada fragmento com metadados de controle de acesso.", "2. Rotear: classificar a pergunta e escolher a estratégia de recuperação.", "3. Recuperar: busca híbrida filtrada às permissões do usuário (com cache verificado primeiro).", "4. Reordenar: reordenar candidatos por precisão; manter os melhores trechos.", "5. Sintetizar: gerar uma resposta citada; opcionalmente revisá-la com um loop avaliador.", "6. Devolver e registrar: entregar a resposta com citações; rastrear e pontuar para avaliação." ], "components": [ "Pipeline de ingestão e fragmentação", "Embeddings + armazenamento vetorial", "Filtro de recuperação com permissões", "Busca híbrida e reranker", "Síntese de resposta com citações", "Cache semântico", "Harness de avaliação e observabilidade" ], "referenceScenario": { "context": "Um assistente interno ilustrativo sobre a wiki de uma empresa, as políticas de RH e TI, e a documentação de engenharia.", "scenario": "Os funcionários fazem perguntas em linguagem natural ('como faço para reembolsar viagem?', 'qual é a política de plantão?'); o assistente responde com citações, sem nunca mostrar documentos que quem pergunta não pode ver, e diz 'não sei' em vez de adivinhar quando a recuperação é fraca.", "technology": "Pipeline de ingestão, embeddings + armazenamento vetorial com metadados de ACL, recuperação híbrida e reranking, um harness de avaliação e rastreamento de consultas.", "load": "Tráfego interno estável com forte sobreposição de consultas (poucas políticas geram a maioria das perguntas), então a taxa de acertos de cache é alta e os embeddings dominam o custo offline.", "results": "Meta de referência: respostas fundamentadas e citadas sem vazamentos de controle de acesso, e uma pontuação de fundamentação mensurável que melhora ao ajustar a recuperação. Trate todos os números como algo a medir no seu corpus, não como garantias." }, "benefits": [ "Transforma o conhecimento interno disperso em respostas instantâneas e citadas.", "A recuperação com permissões previne vazamentos de controle de acesso por construção.", "As citações tornam as respostas verificáveis e geram confiança.", "Um harness de avaliação torna a qualidade mensurável e as melhorias demonstráveis." ], "risks": [ "Vazamentos de controle de acesso se as permissões não forem aplicadas na recuperação.", "Respostas obsoletas quando o corpus muda mais rápido que a reindexação.", "Alucinação confiante quando a recuperação é fraca e o modelo preenche a lacuna.", "Fragmentação ruim que quebra o significado e degrada a recuperação." ], "failureModes": [ "Bypass de permissões: um fragmento herda a ACL errada e aparece nos resultados de um usuário.", "Lacunas de recuperação: o documento certo existe mas a fragmentação ou os embeddings não o encontram.", "Obsolescência: uma resposta cita uma política superada porque a reindexação atrasou.", "Deriva de citação: o trecho citado não apoia de fato a afirmação gerada." ], "lessons": [ "Aplique o controle de acesso dentro da recuperação, não após a geração; filtrar o prompt é tarde demais.", "A maioria dos ganhos de qualidade vem da recuperação (fragmentação, busca híbrida, reranking), não de um modelo maior.", "Torne 'não sei' uma resposta de primeira classe; uma resposta confiante e errada é pior que uma abstenção.", "Monte a avaliação antes de escalar; sem ela, cada mudança é um palpite." ], "kpis": [ { "metric": "Fundamentação", "note": "Proporção de respostas totalmente apoiadas pelos trechos citados; a métrica de qualidade central de um assistente RAG." }, { "metric": "Recall@k de recuperação", "note": "Com que frequência o trecho certo está nos top-k recuperados; a maioria dos erros de resposta remonta a isso." }, { "metric": "Taxa de vazamento de controle de acesso", "note": "Qualquer resposta que mostre um documento ao qual o usuário não podia acessar; a métrica que deve ficar em zero." }, { "metric": "Taxa de acertos de cache e custo por consulta", "note": "Cobertura de perguntas repetidas e custo unitário; uma alta sobreposição deve baratear a maioria das consultas." }, { "metric": "Qualidade de abstenção", "note": "Com que frequência o assistente diz corretamente 'não sei' em vez de alucinar diante de uma recuperação fraca." } ], "scaling": [ "A incorporação e indexação offline dominam o custo de ingestão e crescem com o tamanho do corpus e a frequência de atualização.", "O custo na consulta é principalmente recuperação + geração; o reranking adiciona latência que você troca por precisão.", "O cache achata o custo à medida que a sobreposição de consultas sobe, então o custo unitário cai com a adoção.", "A cadência de reindexação é a real tensão de escala: respostas mais frescas custam mais computação." ], "examples": [ "Um funcionário perguntando a política de reembolso de viagem e obtendo uma resposta citada e atualizada.", "Uma pergunta sobre um projeto restrito devolvendo corretamente nada para um usuário não autorizado.", "Uma consulta com recuperação fraca respondida com 'não tenho uma fonte confiável para isso' em vez de adivinhar." ], "faqs": [ { "q": "Isso não é só RAG?", "a": "RAG é o núcleo, mas a arquitetura é definida pelo que a torna segura para a empresa: recuperação com permissões, citações, um harness de avaliação e observabilidade. Essas são as partes que decidem se ela pode ser confiável." }, { "q": "Por que aplicar permissões durante a recuperação?", "a": "Para que o modelo nunca veja documentos aos quais o usuário não pode acessar. Filtrar após a geração é tarde demais: o conteúdo já poderia ter vazado na resposta." }, { "q": "Como evitar que as respostas aluciem?", "a": "Fundamente cada resposta em trechos recuperados com citações, meça a fundamentação contra um conjunto de avaliação, e deixe o assistente se abster quando a recuperação for fraca em vez de preencher a lacuna." } ] }, "fr": { "name": "Assistant de connaissances d'entreprise", "summary": "Une architecture de référence pour un assistant de connaissances interne qui répond aux questions des employés à partir des propres documents de l'entreprise — wikis, politiques, tickets, code — avec des citations et dans le respect des autorisations d'accès de chaque utilisateur. Elle combine recherche hybride et réordonnancement pour l'ancrage, filtrage basé sur les autorisations pour la sécurité, et un harnais d'évaluation afin que la qualité des réponses soit mesurée plutôt que supposée. Les aspects les plus complexes ne concernent pas le modèle, mais la qualité de la recherche, le contrôle d'accès et l'évaluation.", "keyConcepts": [ "Recherche respectueuse des autorisations : un utilisateur ne récupère jamais que les documents qu'il est autorisé à voir.", "Recherche hybride + réordonnancement : combiner la recherche par mots-clés et vectorielle, puis réordonner pour plus de précision.", "Citations : chaque réponse renvoie à ses passages sources pour vérification.", "Évaluation : la qualité des réponses est notée en continu par rapport à un ensemble de référence." ], "definition": "L'architecture de l'assistant de connaissances d'entreprise est un système RAG respectueux des autorisations qui répond aux questions des employés à partir de documents internes avec des citations, limité aux droits d'accès de chaque utilisateur et évalué en continu pour en garantir la qualité.", "architecture": [ "Le contenu provenant de nombreuses sources internes est ingéré, découpé et vectorisé dans une base de données vectorielle, chaque fragment étant étiqueté avec les métadonnées de contrôle d'accès de son document source. Lors de la requête, l'assistant oriente la question, exécute une recherche hybride (mots-clés + vectorielle) filtrée selon les autorisations de l'utilisateur, réordonne les candidats et synthétise une réponse citée à partir des meilleurs passages.", "La sécurité est structurelle et non surajoutée : le filtre de contrôle d'accès est appliqué lors de la recherche, de sorte que le modèle ne voit jamais les documents auxquels l'utilisateur ne peut pas accéder. Un cache sémantique répond à moindre coût aux questions répétées, et des garde-fous maintiennent les réponses conformes aux politiques tout en signalant les cas de faible confiance.", "La qualité est régie par la mesure : un harnais d'évaluation note les réponses pour leur ancrage, leur exactitude et la précision des citations par rapport à un ensemble de référence, et une boucle optionnelle d'évaluation-optimisation révise les réponses faibles avant qu'elles n'atteignent l'utilisateur. L'observabilité trace chaque requête afin que les défaillances puissent être diagnostiquées et réintégrées dans les évaluations." ], "flow": [ "1. Ingestion (hors ligne) : découper et vectoriser les documents ; étiqueter chaque fragment avec les métadonnées de contrôle d'accès.", "2. Routage : classifier la question et choisir la stratégie de recherche.", "3. Recherche : recherche hybride filtrée selon les autorisations de l'utilisateur (après vérification du cache).", "4. Réordonnancement : réordonner les candidats pour plus de précision ; conserver les meilleurs passages.", "5. Synthèse : générer une réponse citée ; éventuellement la réviser via une boucle d'évaluation.", "6. Retour et journalisation : fournir la réponse avec les citations ; tracer et noter pour l'évaluation." ], "components": [ "Pipeline d'ingestion et de découpage", "Vectorisations + base de données vectorielle", "Filtre de recherche respectueux des autorisations", "Recherche hybride et réordonnanceur", "Synthèse des réponses avec citations", "Cache sémantique", "Harnais d'évaluation et observabilité" ], "referenceScenario": { "context": "Un assistant interne illustratif couvrant le wiki de l'entreprise, les politiques RH et informatiques, ainsi que les documents d'ingénierie.", "scenario": "Les employés posent des questions en langage naturel (« comment déclarer mes frais de déplacement ? », « quelle est notre politique d'astreinte ? ») ; l'assistant répond avec des citations, sans jamais afficher de documents auxquels le demandeur ne peut pas accéder, et dit « Je ne sais pas » plutôt que de deviner lorsque la recherche est peu concluante.", "technology": "Pipeline d'ingestion, vectorisations + base de données vectorielle avec métadonnées ACL, recherche hybride et réordonnancement, harnais d'évaluation et traçage des requêtes.", "load": "Trafic interne régulier avec un fort chevauchement des requêtes (quelques politiques concentrent la plupart des questions), de sorte que le taux de réussite du cache est élevé et que les vectorisations dominent le coût hors ligne.", "results": "Cible de référence : des réponses ancrées et citées sans fuite de contrôle d'accès, et un score d'ancrage mesurable qui s'améliore à mesure que la recherche est optimisée. Considérez tous les chiffres comme des éléments à mesurer sur votre corpus, et non comme des garanties." }, "benefits": [ "Transforme les connaissances internes dispersées en réponses instantanées et citées.", "La recherche respectueuse des autorisations empêche par construction les fuites de contrôle d'accès.", "Les citations rendent les réponses vérifiables et renforcent la confiance des utilisateurs.", "Un harnais d'évaluation rend la qualité mesurable et les améliorations démontrables." ], "risks": [ "Fuites de contrôle d'accès si les autorisations ne sont pas appliquées lors de la recherche.", "Réponses obsolètes lorsque le corpus de documents change plus rapidement que la réindexation.", "Hallucination affirmée lorsque la recherche est peu concluante et que le modèle comble le vide.", "Mauvais découpage qui fragmente le sens et dégrade la recherche." ], "failureModes": [ "Contournement des autorisations : un fragment hérite d'une mauvaise ACL et apparaît dans les résultats d'un utilisateur.", "Lacunes de recherche : le bon document existe mais le découpage ou les vectorisations le manquent.", "Obsolescence : une réponse cite une politique obsolète en raison d'un retard de réindexation.", "Dérive de citation : le passage cité ne soutient pas réellement l'affirmation générée." ], "lessons": [ "Appliquez le contrôle d'accès lors de la recherche, pas après la génération — filtrer le prompt est trop tardif.", "La plupart des gains de qualité proviennent de la recherche (découpage, recherche hybride, réordonnancement), et non d'un modèle plus grand.", "Faites de « Je ne sais pas » une réponse de premier ordre ; une réponse fausse mais affirmée est pire qu'une abstention.", "Mettez en place l'évaluation avant de passer à l'échelle ; sans elle, chaque modification est une conjecture." ], "kpis": [ { "metric": "Ancrage", "note": "Part des réponses entièrement soutenues par les passages cités ; la métrique de qualité fondamentale pour un assistant RAG." }, { "metric": "Rappel de recherche@k", "note": "Fréquence à laquelle le bon passage figure parmi les k premiers résultats récupérés ; la plupart des erreurs de réponse proviennent de là." }, { "metric": "Taux de fuite de contrôle d'accès", "note": "Toute réponse affichant un document auquel l'utilisateur ne pouvait pas accéder — la métrique qui doit impérativement rester à zéro." }, { "metric": "Taux de réussite du cache et coût par requête", "note": "Couverture des questions répétées et coût unitaire ; un fort chevauchement devrait rendre la plupart des requêtes peu coûteuses." }, { "metric": "Qualité de l'abstention", "note": "Fréquence à laquelle l'assistant dit correctement « Je ne sais pas » au lieu d'halluciner lors d'une recherche peu concluante." } ], "scaling": [ "La vectorisation et l'indexation hors ligne dominent le coût d'ingestion et augmentent avec la taille du corpus et la fréquence des mises à jour.", "Le coût lors de la requête réside principalement dans la recherche et la génération ; le réordonnancement ajoute de la latence que vous échangez contre de la précision.", "Le cache stabilise le coût à mesure que le chevauchement des requêtes augmente, de sorte que le coût unitaire diminue avec l'adoption.", "La cadence de réindexation est la véritable tension du passage à l'échelle : des réponses plus fraîches nécessitent plus de puissance de calcul." ], "examples": [ "Un employé demandant la politique de frais de déplacement et obtenant une réponse citée et à jour.", "Une question sur un projet restreint ne renvoyant correctement aucun résultat pour un utilisateur non autorisé.", "Une requête avec une recherche peu concluante recevant pour réponse « Je ne dispose pas d'une source fiable pour cela » au lieu d'une conjecture." ], "faqs": [ { "q": "N'est-ce pas simplement du RAG ?", "a": "Le RAG en est le cœur, mais l'architecture se définit par ce qui la rend sûre pour l'entreprise : recherche respectueuse des autorisations, citations, harnais d'évaluation et observabilité. Ce sont ces éléments qui déterminent si l'on peut lui faire confiance." }, { "q": "Pourquoi appliquer les autorisations lors de la recherche ?", "a": "Pour que le modèle ne voie jamais les documents auxquels l'utilisateur ne peut pas accéder. Filtrer après la génération est trop tardif — le contenu pourrait déjà avoir fui dans la réponse." }, { "q": "Comment empêcher les réponses d'halluciner ?", "a": "Ancrez chaque réponse dans les passages récupérés avec des citations, mesurez l'ancrage par rapport à un ensemble d'évaluation et laissez l'assistant s'abstenir lorsque la récupération est faible plutôt que de combler le vide." } ] }, "de": { "name": "Enterprise Knowledge Assistant", "summary": "Eine Referenzarchitektur für einen internen Wissensassistenten, der Fragen von Mitarbeitenden auf Basis unternehmenseigener Dokumente – Wikis, Richtlinien, Tickets, Code – beantwortet, inklusive Quellenangaben und unter Berücksichtigung der jeweiligen Zugriffsberechtigungen. Sie kombiniert hybrides Retrieval und Reranking für das Grounding, berechtigungsbasiertes Filtern für die Sicherheit und ein Evaluation Harness, damit die Antwortqualität gemessen statt nur vorausgesetzt wird. Die Herausforderungen liegen nicht im Modell, sondern in der Retrieval-Qualität, der Zugriffskontrolle und der Evaluierung.", "keyConcepts": [ "Berechtigungsbasiertes Retrieval: Ein Benutzer ruft immer nur Dokumente ab, die er auch sehen darf.", "Hybride Suche + Reranking: Kombination aus Keyword- und Vektorsuche mit anschließendem Reranking für maximale Präzision.", "Quellenangaben: Jede Antwort verweist zur Überprüfung direkt auf die zugrunde liegenden Textpassagen.", "Evaluierung: Die Antwortqualität wird kontinuierlich anhand eines kuratierten Testsets bewertet." ], "definition": "Die Architektur des Enterprise Knowledge Assistant ist ein berechtigungsbasiertes RAG-System, das Fragen von Mitarbeitenden auf Basis interner Dokumente mit Quellenangaben beantwortet, abgestimmt auf die Zugriffsrechte des jeweiligen Benutzers und kontinuierlich auf Qualität evaluiert.", "architecture": [ "Inhalte aus verschiedenen internen Quellen werden erfasst, in Chunks unterteilt und in einem Vektorspeicher abgelegt, wobei jeder Chunk mit den Metadaten zur Zugriffskontrolle des Quelldokuments versehen wird. Bei einer Anfrage leitet der Assistent die Frage weiter, führt ein hybrides Retrieval (Keyword + Vektor) gefiltert nach den Berechtigungen des Benutzers aus, führt ein Reranking der Kandidaten durch und generiert eine Antwort mit Quellenangaben aus den besten Textpassagen.", "Sicherheit ist strukturell verankert, nicht nachträglich aufgesetzt: Der Filter zur Zugriffskontrolle wird bereits beim Retrieval angewendet, sodass das Modell Dokumente, auf die der Benutzer keinen Zugriff hat, gar nicht erst zu Gesicht bekommt. Ein semantischer Cache beantwortet wiederkehrende Fragen kostengünstig, während Guardrails sicherstellen, dass Antworten den Richtlinien entsprechen, und Fälle mit geringer Konfidenz markieren.", "Qualität wird durch Messung gesteuert: Ein Evaluation Harness bewertet Antworten auf Groundedness, Korrektheit und Genauigkeit der Quellenangaben anhand eines kuratierten Testsets, und ein optionaler Evaluator-Optimizer-Loop überarbeitet schwache Antworten, bevor sie den Benutzer erreichen. Observability zeichnet jede Anfrage auf, sodass Fehler diagnostiziert und in die Evaluierungen zurückgeführt werden können." ], "flow": [ "1. Ingest (offline): Dokumente in Chunks unterteilen und einbetten; jeden Chunk mit Metadaten zur Zugriffskontrolle versehen.", "2. Route: Die Frage klassifizieren und die Retrieval-Strategie auswählen.", "3. Retrieve: Hybride Suche, gefiltert nach den Berechtigungen des Benutzers (zuerst Prüfung des Cache).", "4. Rerank: Kandidaten für höhere Präzision neu ordnen; die besten Passagen behalten.", "5. Synthesize: Eine Antwort mit Quellenangaben generieren; optional über einen Evaluator-Loop überarbeiten.", "6. Return & log: Antwort mit Quellenangaben ausgeben; für die Evaluierung aufzeichnen und bewerten." ], "components": [ "Ingestion- & Chunking-Pipeline", "Embeddings + Vektorspeicher", "Berechtigungsbasierter Retrieval-Filter", "Hybride Suche & Reranker", "Antwortsynthese mit Quellenangaben", "Semantischer Cache", "Evaluation Harness & Observability" ], "referenceScenario": { "context": "Ein anschaulicher interner Assistent für das Wiki, die HR- und IT-Richtlinien sowie die Engineering-Dokumente eines Unternehmens.", "scenario": "Mitarbeitende stellen Fragen in natürlicher Sprache („Wie rechne ich Reisekosten ab?“, „Wie sieht unsere On-Call-Regelung aus?“); der Assistent antwortet mit Quellenangaben, zeigt niemals Dokumente an, auf die der Fragesteller keinen Zugriff hat, und antwortet bei unzureichendem Retrieval mit „Das weiß ich nicht“, statt zu raten.", "technology": "Ingestion-Pipeline, Embeddings + Vektorspeicher mit ACL-Metadaten, hybrides Retrieval und Reranking, ein Evaluation Harness und Query-Tracing.", "load": "Gleichmäßiger interner Traffic mit starker Überschneidung der Anfragen (einige wenige Richtlinien machen die meisten Fragen aus), sodass die Cache-Hit-Rate hoch ist und die Embeddings die Offline-Kosten dominieren.", "results": "Referenzziel: Fundierte Antworten mit Quellenangaben ohne Verletzung von Zugriffsrechten sowie ein messbarer Groundedness-Score, der sich durch die Optimierung des Retrievals verbessert. Betrachten Sie alle Zahlen als Messwerte für Ihr eigenes Korpus, nicht als Garantien." }, "benefits": [ "Verwandelt verstreutes internes Wissen in sofortige Antworten mit Quellenangaben.", "Berechtigungsbasiertes Retrieval verhindert systembedingt die Verletzung von Zugriffsrechten.", "Quellenangaben machen Antworten überprüfbar und schaffen Vertrauen bei den Benutzern.", "Ein Evaluation Harness macht Qualität messbar und Verbesserungen nachweisbar." ], "risks": [ "Verletzung von Zugriffsrechten, wenn Berechtigungen nicht bereits beim Retrieval erzwungen werden.", "Veraltete Antworten, wenn sich das Dokumentenkorpus schneller ändert als die Neuindexierung erfolgt.", "Überzeugend formulierte Halluzinationen, wenn das Retrieval unzureichend ist und das Modell die Lücken füllt.", "Mangelhaftes Chunking, das Sinnzusammenhänge fragmentiert und das Retrieval verschlechtert." ], "failureModes": [ "Umgehung von Berechtigungen: Ein Chunk erbt die falsche ACL und taucht in den Ergebnissen eines Benutzers auf.", "Retrieval-Lücken: Das richtige Dokument existiert, wird aber durch das Chunking oder die Embeddings nicht erfasst.", "Veraltete Daten: Eine Antwort zitiert eine überholte Richtlinie, weil die Neuindexierung verzögert war.", "Abweichende Quellenangaben: Die zitierte Passage stützt die generierte Aussage nicht tatsächlich." ], "lessons": [ "Erzwingen Sie die Zugriffskontrolle direkt beim Retrieval, nicht erst nach der Generierung – das Filtern des Prompts ist zu spät.", "Die meisten Qualitätsgewinne resultieren aus dem Retrieval (Chunking, hybride Suche, Reranking), nicht aus einem größeren Modell.", "Etablieren Sie „Das weiß ich nicht“ als vollwertige Antwort; eine falsche, aber überzeugend formulierte Antwort ist schlimmer als eine Enthaltung.", "Etablieren Sie die Evaluierung vor der Skalierung; ohne sie ist jede Änderung nur ein Ratespiel." ], "kpis": [ { "metric": "Groundedness", "note": "Anteil der Antworten, die vollständig durch die zitierten Passagen gestützt werden; die zentrale Qualitätsmetrik für einen RAG-Assistenten." }, { "metric": "Retrieval-Recall@k", "note": "Wie oft sich die richtige Passage unter den Top-k abgerufenen Ergebnissen befindet; die meisten Antwortfehler lassen sich darauf zurückführen." }, { "metric": "Verletzungsrate der Zugriffskontrolle", "note": "Jede Antwort, die ein Dokument offenlegt, auf das der Benutzer keinen Zugriff hatte – diese Metrik muss zwingend bei null bleiben." }, { "metric": "Cache-Hit-Rate & Kosten pro Anfrage", "note": "Abdeckung wiederkehrender Fragen und Stückkosten; eine hohe Überschneidung sollte die meisten Anfragen kostengünstig machen." }, { "metric": "Enthaltungsqualität", "note": "Wie oft der Assistent korrekterweise „Das weiß ich nicht“ antwortet, anstatt bei unzureichendem Retrieval zu halluzinieren." } ], "scaling": [ "Offline-Embedding und -Indexierung dominieren die Ingestion-Kosten und steigen mit der Größe des Korpus und der Aktualisierungshäufigkeit.", "Die Kosten zur Abfragezeit entfallen hauptsächlich auf Retrieval + Generierung; Reranking erhöht die Latenz im Austausch für höhere Präzision.", "Der Cache dämpft die Kosten bei steigender Überschneidung der Anfragen, sodass die Stückkosten mit zunehmender Nutzung sinken.", "Die Taktung der Neuindexierung ist der eigentliche kritische Faktor bei der Skalierung: Aktuellere Antworten erfordern mehr Rechenleistung." ], "examples": [ "Ein Mitarbeiter fragt nach den Reisekostenrichtlinien und erhält eine aktuelle Antwort mit Quellenangaben.", "Eine Frage zu einem geschützten Projekt liefert für einen nicht autorisierten Benutzer korrekterweise kein Ergebnis.", "Eine Anfrage mit unzureichendem Retrieval wird mit „Dazu liegt mir keine verlässliche Quelle vor“ beantwortet, statt zu raten." ], "faqs": [ { "q": "Ist das nicht einfach nur RAG?", "a": "RAG bildet den Kern, aber die Architektur zeichnet sich durch das aus, was sie unternehmenstauglich macht: berechtigungsbasiertes Retrieval, Quellenangaben, ein Evaluation Harness und Observability. Das sind die Komponenten, die darüber entscheiden, ob man dem System vertrauen kann." }, { "q": "Warum sollten Berechtigungen bereits beim Retrieval erzwungen werden?", "a": "Damit das Modell Dokumente, auf die der Benutzer keinen Zugriff hat, gar nicht erst zu Gesicht bekommt. Ein Filtern nach der Generierung ist zu spät – der Inhalt könnte bereits in die Antwort eingeflossen sein." }, { "q": "Wie verhindert man, dass Antworten halluziniert werden?", "a": "Verankern Sie jede Antwort in den abgerufenen Passagen mit Quellenangaben, messen Sie die Fundierung (Groundedness) anhand eines Evaluierungssets und lassen Sie den Assistenten bei schwachem Abruf lieber auf eine Antwort verzichten, anstatt die Lücke zu füllen." } ] }, "ja": { "name": "エンタープライズナレッジアシスタント", "summary": "社内文書（Wiki、ポリシー、チケット、コードなど）から、各ユーザーのアクセス権限を尊重し、引用元を明示しながら従業員の質問に回答する社内ナレッジアシスタントのリファレンスアーキテクチャです。グラウンディングのためのハイブリッド検索とリランキング、セキュリティのための権限対応フィルタリング、そして回答の品質を推測ではなく測定可能にする評価ハーネスを組み合わせています。難しいのはモデルではなく、検索の品質、アクセス制御、および評価です。", "keyConcepts": [ "権限対応の検索：ユーザーは閲覧を許可されている文書のみを検索・取得します。", "ハイブリッド検索 ＋ リランキング：キーワード検索とベクトル検索を組み合わせ、精度向上のためにリランキングを行います。", "引用：すべての回答は、検証のためにソースとなった一節へのリンクを明示します。", "評価：厳選されたデータセットに対して、回答の品質を継続的にスコアリングします。" ], "definition": "エンタープライズナレッジアシスタントのアーキテクチャは、社内文書から引用付きで従業員の質問に回答する、権限対応のRAGシステムです。各ユーザーのアクセス権限の範囲内に限定され、品質が継続的に評価されます。", "architecture": [ "多数 of 社内ソースからのコンテンツが取り込まれ（インジェスト）、チャンク分割されてベクトルストアに埋め込まれます。各チャンクには、ソース文書のアクセス制御メタデータがタグ付けされます。クエリ実行時、アシスタントは質問をルーティングし、ユーザーの権限でフィルタリングされたハイブリッド検索（キーワード ＋ ベクトル）を実行し、候補をリランキングして、上位の一節から引用付きの回答を合成します。", "セキュリティは後付けではなく構造的なものです。アクセス制御フィルターは検索時に適用されるため、モデルはユーザーがアクセスできない文書を目にすることさえありません。セマンティックキャッシュにより、繰り返される質問に低コストで対応し、ガードレールによって回答をポリシー内に収め、信頼性の低いケースにフラグを立てます。", "品質は測定によって管理されます。評価ハーネスが、厳選されたデータセットに対して回答のグラウンディング（根拠性）、正確性、および引用の精度をスコアリングし、オプションの評価者-最適化者（evaluator-optimizer）ループが、ユーザーに届く前に不十分な回答を修正します。オブザーバビリティによりすべてのクエリがトレースされるため、失敗を診断して評価（eval）にフィードバックできます。" ], "flow": [ "1. 取り込み（オフライン）：文書をチャンク分割して埋め込み、各チャンクにアクセス制御メタデータをタグ付けします。", "2. ルーティング：質問を分類し、検索戦略を選択します。", "3. 検索：ユーザーの権限でフィルタリングされたハイブリッド検索を実行します（最初にキャッシュを確認します）。", "4. リランキング：精度向上のために候補を並べ替え、上位の一節を保持します。", "5. 合成：引用付きの回答を生成します。オプションで評価者ループを介して修正します。", "6. 返却とログ記録：引用付きで回答を提供し、評価のためにトレースとスコアリングを行います。" ], "components": [ "取り込み＆チャンク分割パイプライン", "埋め込み ＋ ベクトルストア", "権限対応の検索フィルター", "ハイブリッド検索 ＆ リランカー", "引用付きの回答合成", "セマンティックキャッシュ", "評価ハーネス ＆ オブザーバビリティ" ], "referenceScenario": { "context": "会社のWiki、人事およびITポリシー、エンジニアリング文書を対象とした、社内アシスタントの図解例。", "scenario": "従業員が自然言語で質問し（例：「出張費の精算方法は？」、「オンコールポリシーは？」）、アシスタントは引用付きで回答します。質問者がアクセス権を持たない文書は決して表示せず、検索結果が不十分な場合は推測で答えず「わかりません」と回答します。", "technology": "取り込みパイプライン、ACLメタデータ付きの埋め込み ＋ ベクトルストア、ハイブリッド検索とリランキング、評価ハーネス、およびクエリトレース。", "load": "クエリの重複が多い安定した社内トラフィック（少数のポリシーがほとんどの質問を占める）であるため、キャッシュヒット率が高く、オフラインコストは埋め込みが大部分を占めます。", "results": "リファレンス目標：アクセス制御の漏洩がなく、根拠があり引用が明示された回答、および検索のチューニングに伴って向上する測定可能なグラウンディングスコア。すべての数値は、保証ではなく、ご自身のコーパスで測定すべき指標として扱ってください。" }, "benefits": [ "散在する社内ナレッジを、即座に得られる引用付きの回答に変換します。", "権限対応の検索により、構造的にアクセス制御の漏洩を防ぎます。", "引用により回答の検証が可能になり、ユーザーの信頼を築きます。", "評価ハーネスにより品質が測定可能になり、改善を実証できるようになります。" ], "risks": [ "検索時に権限が強制されない場合、アクセス制御の漏洩が発生します。", "再インデックスよりも早く文書コーパスが変更されると、古い回答が返されます。", "検索結果が不十分な場合に、モデルがそのギャップを埋めることで、もっともらしいハルシネーションが発生します。", "不適切なチャンク分割により意味が断片化し、検索精度が低下します。" ], "failureModes": [ "権限のバイパス：チャンクが誤ったACLを継承し、ユーザーの検索結果に表示されてしまう。", "検索のギャップ：適切な文書が存在するにもかかわらず、チャンク分割や埋め込みの不備により見落とされる。", "情報の陳腐化：再インデックスの遅れにより、回答が古いポリシーを引用してしまう。", "引用の乖離：引用された一節が、生成された主張を実際には裏付けていない。" ], "lessons": [ "アクセス制御は生成後ではなく、検索の内部で強制します。プロンプトのフィルタリングでは遅すぎます。", "品質向上の大部分は、より大きなモデルからではなく、検索（チャンク分割、ハイブリッド検索、リランキング）から得られます。", "『わかりません』を第一級の回答とします。自信ありげな誤った回答は、回答を棄権することよりも悪影響を及ぼします。", "スケールアップする前に評価体制を確立します。これがないと、すべての変更が単なる推測になってしまいます。" ], "kpis": [ { "metric": "グラウンディング（根拠性）", "note": "引用された一節によって完全に裏付けられている回答の割合。RAGアシスタントのコア品質指標です。" }, { "metric": "検索の再現率（Recall@k）", "note": "適切な一節が検索結果の上位k件に含まれる頻度。回答エラーのほとんどはこれに起因します。" }, { "metric": "アクセス制御の漏洩率", "note": "ユーザーがアクセスできない文書を提示してしまった回答の割合。常にゼロに維持すべき指標です。" }, { "metric": "キャッシュヒット率 ＆ クエリあたりのコスト", "note": "繰り返される質問のカバー率と単価。重複度が高ければ、ほとんどのクエリを低コストに抑えられます。" }, { "metric": "棄権の品質", "note": "検索結果が不十分な場合に、ハルシネーションを起こさず、アシスタントが正しく『わかりません』と回答する頻度。" } ], "scaling": [ "オフラインでの埋め込みとインデックス作成が取り込みコストの大部分を占め、コーパスのサイズと更新頻度に応じて増加します。", "クエリ実行時のコストは主に検索 ＋ 生成です。リランキングは精度とのトレードオフでレイテンシーを増加させます。", "クエリの重複が増えるにつれてキャッシュがコストを平準化するため、導入が進むほどユニットコストは低下します。", "再インデックスの頻度は、スケーリングにおける真の対立点です。より新しい回答を提供するには、より多くの計算コストがかかります。" ], "examples": [ "従業員が出張費ポリシーについて質問し、引用付きの最新の回答を得る。", "権限のないユーザーが制限されたプロジェクトについて質問した際、正しく何も返さない。", "検索結果が不十分なクエリに対し、推測ではなく『確実な情報源が見つかりませんでした』と回答する。" ], "faqs": [ { "q": "これは単なるRAGではないのですか？", "a": "RAGがコアですが、このアーキテクチャは、権限対応の検索、引用、評価ハーネス、オブザーバビリティといった、エンタープライズレベルの安全性を確保する要素によって定義されます。これらこそが、信頼できるかどうかを決定する部分です。" }, { "q": "なぜ検索時に権限を強制するのですか？", "a": "モデルが、ユーザーのアクセスできない文書を目にしないようにするためです。生成後にフィルタリングするのでは遅すぎます。コンテンツがすでに回答に漏洩している可能性があります。" }, { "q": "回答のハルシネーションを防ぐにはどうすればよいですか？", "a": "すべての回答を引用付きの取得済みパッセージに根拠付け（グラウンディング）し、評価セットに対してグラウンディング性を測定します。また、取得結果が不十分な場合は、隙間を埋めるような回答をするのではなく、アシスタントに回答を控えさせます。" } ] }, "zh": { "name": "企业知识助手", "summary": "内部知识助手的参考架构，该助手可根据公司自身的文档（Wiki、政策、工单、代码）回答员工的问题，并提供引用出处，同时遵循每个用户的访问权限。它结合了用于 Grounding 的混合检索与重排、用于保障安全的权限感知过滤，以及一个评估系统（evaluation harness），从而使回答质量能够被量化评估而非凭空假设。难点不在于模型，而在于检索质量、访问控制和评估。", "keyConcepts": [ "权限感知检索：用户只能检索到其有权查看的文档。", "混合搜索 + 重排：结合关键字搜索与向量搜索，然后进行重排以提高精度。", "引用出处：每个回答都链接回其源段落以供验证。", "评估：持续对照精选测试集对回答质量进行评分。" ], "definition": "企业知识助手架构是一种具备权限感知能力的 RAG 系统，它能根据内部文档回答员工的问题并提供引用出处，其范围限定于每个用户的访问权限内，并对回答质量进行持续评估。", "architecture": [ "来自多个内部源的内容被摄取、分块（chunked）并嵌入到向量数据库中，每个分块都标记有其源文档的访问控制元数据。在查询时，助手会路由问题，运行过滤了用户权限的混合检索（关键字 + 向量），对候选结果进行重排，并根据排名靠前的段落合成带有引用出处的回答。", "安全是结构性的，而非事后修补：访问控制过滤器在检索期间应用，因此模型根本不会接触到用户无权访问的文档。语义缓存以极低的成本响应重复问题，而安全护栏则确保回答符合政策并标记低置信度的案例。", "质量由度量主导：评估系统（evaluation harness）对照精选测试集对回答的真实性（groundedness）、正确性和引用准确性进行评分，可选的“评估器-优化器”循环会在弱回答到达用户之前对其进行修正。可观测性会追踪每一次查询，以便诊断故障并反馈到评估中。" ], "flow": [ "1. 摄取（离线）：对文档进行分块和嵌入；用访问控制元数据标记每个分块。", "2. 路由：对问题进行分类并选择检索策略。", "3. 检索：运行过滤了用户权限的混合搜索（首先检查缓存）。", "4. 重排：重新排列候选结果以提高精度；保留排名靠前的段落。", "5. 合成：生成带有引用出处的回答；可选地通过评估器循环进行修正。", "6. 返回与记录：交付带有引用出处的回答；进行追踪并评分以供评估。" ], "components": [ "摄取与分块流水线", "嵌入 + 向量数据库", "权限感知检索过滤器", "混合搜索与重排器", "带有引用出处的回答合成", "语义缓存", "评估系统与可观测性" ], "referenceScenario": { "context": "一个针对公司 Wiki、HR 和 IT 政策以及工程文档的示例性内部助手。", "scenario": "员工提出自然语言问题（如“如何报销差旅费？”、“我们的值班政策是什么？”）；助手在回答时提供引用出处，绝不呈现提问者无权访问的文档，并在检索效果不佳时回答“我不知道”，而不是凭空猜测。", "technology": "摄取流水线、带有 ACL 元数据的嵌入 + 向量数据库、混合检索与重排、评估系统以及查询追踪。", "load": "稳定的内部流量且查询重合度高（少数几项政策占了大部分问题），因此缓存命中率高，而嵌入占了离线成本的大部分。", "results": "参考目标：提供有真实依据、有引用出处的回答，无访问控制泄露，且具备可度量的真实性（groundedness）评分（该评分会随着检索的微调而提高）。请将所有数据视为在您自己的语料库上需要度量的指标，而非保证值。" }, "benefits": [ "将零散的内部知识转化为即时、有引用出处的回答。", "权限感知检索从架构设计上防止了访问控制泄露。", "引用出处使回答可验证，从而建立用户信任。", "评估系统使质量可度量，并使改进效果显而易见。" ], "risks": [ "如果在检索时未强制执行权限控制，会导致访问控制泄露。", "当文档语料库的变化速度快于重新索引的速度时，会导致回答过时。", "当检索效果不佳且模型自行填补空白时，会导致言之凿凿的幻觉。", "糟糕的分块会导致语义碎片化并降低检索质量。" ], "failureModes": [ "权限绕过：分块继承了错误的 ACL，并出现在用户的检索结果中。", "检索遗漏：正确的文档存在，但分块或嵌入未能匹配到它。", "过时：由于重新索引滞后，回答引用了已被取代的政策。", "引用偏差：引用的段落实际上并不支持生成的陈述。" ], "lessons": [ "在检索内部强制执行访问控制，而不是在生成之后——在 Prompt 中进行过滤为时已晚。", "大多数质量提升来自于检索（分块、混合搜索、重排），而不是来自于更大的模型。", "将“我不知道”作为首要的回答选项；言之凿凿的错误回答比弃权不答更糟糕。", "在规模化之前建立评估机制；没有它，每一次改动都只是猜测。" ], "kpis": [ { "metric": "真实性（Groundedness）", "note": "完全由引用段落支持的回答比例；这是 RAG 助手的核心质量指标。" }, { "metric": "检索召回率 recall@k", "note": "正确段落出现在前 k 个检索结果中的频率；大多数回答错误都可以追溯到这一点。" }, { "metric": "访问控制泄露率", "note": "任何呈现了用户无权访问文档的回答——该指标必须保持为零。" }, { "metric": "缓存命中率与单次查询成本", "note": "重复问题的覆盖率和单位成本；高重合度应该会让大多数查询变得非常便宜。" }, { "metric": "弃权质量", "note": "在检索效果不佳时，助手正确回答“我不知道”而不是产生幻觉的频率。" } ], "scaling": [ "离线嵌入和索引占了摄取成本的大部分，并随着语料库规模和更新频率的增加而增长。", "查询时的成本主要是检索 + 生成；重排会增加延迟，这是为了换取精度而做出的权衡。", "随着查询重合度的提高，缓存会平抑成本，因此单位成本会随着采用率的增加而下降。", "重新索引的节奏是真正的扩展张力所在：更新鲜的回答需要消耗更多的计算资源。" ], "examples": [ "员工询问差旅报销政策，并获得有引用出处的最新回答。", "针对受限项目的提问，对未授权用户正确地不返回任何内容。", "检索效果不佳的查询，回答为“我没有可靠的来源来回答该问题”，而不是凭空猜测。" ], "faqs": [ { "q": "这不就是 RAG 吗？", "a": "RAG 是核心，但该架构的定义特征在于使其具备企业级安全性的要素：权限感知检索、引用出处、评估系统和可观测性。正是这些部分决定了它是否值得信赖。" }, { "q": "为什么要在检索期间强制执行权限控制？", "a": "这样模型就永远不会接触到用户无权访问的文档。在生成之后进行过滤为时已晚——内容可能已经泄露到回答中了。" }, { "q": "如何防止回答产生幻觉？", "a": "将每个回答都基于检索到的段落并附带引用，对照评估集衡量其真实性（groundedness），并在检索结果较弱时让助手选择弃权，而不是凭空填充。" } ] } } }, { "id": "ARCH-003", "slug": "sales-copilot", "category": "sales", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/architectures/sales-copilot", "api": "https://santismm.com/api/architectures/sales-copilot", "canonical_url": "https://santismm.com/en/architectures/sales-copilot", "api_url": "https://santismm.com/api/architectures/sales-copilot", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "medium", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "CRM integration (function calling)", "RAG over product & deal data", "Email & calendar tools", "Orchestration loop", "Guardrails", "Observability (LangSmith / Langfuse)" ], "patterns": [ "routing", "human-approval-gate", "reflection", "semantic-caching" ], "knowledge": [ "ai-agent", "tool-use", "enterprise-rag", "context-engineering", "guardrails", "ai-observability" ], "references": [ { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "related": [ "customer-service-agent", "enterprise-knowledge-assistant" ], "locales": { "en": { "name": "Sales Copilot", "summary": "A sales copilot is an agent that assists reps end to end: it researches accounts from CRM and product data, drafts personalized outreach and follow-ups, logs activity, surfaces next-best-actions, and prepares meeting briefs. Everything is grounded in the company's CRM, deal, and product knowledge to avoid hallucinated claims about features or pricing. The rep stays in control: a human-approval gate sits in front of any outbound action, so the agent drafts but never sends to a customer on its own. Success is measured honestly through rep productivity and pipeline impact, not vanity activity counts.", "keyConcepts": [ "Grounding in CRM, deal, and product data so the agent reasons over the rep's real pipeline instead of generic assumptions.", "A strict separation between drafting and sending, with a human-approval gate on every customer-facing action.", "Tool use via function calling to read and write CRM records, search product knowledge, and schedule meetings.", "Honest measurement of rep productivity and pipeline outcomes rather than raw volume of emails or logged tasks." ], "definition": "The sales copilot architecture is an agentic assistant that grounds account research, outreach drafting, and activity logging in CRM and product data while keeping a rep approval gate before anything reaches a customer.", "architecture": [ "At the core sits an orchestration loop that interprets the rep's intent, plans a short sequence of tool calls, and assembles context. A router classifies each request — research an account, draft an email, log a call, prepare a brief, or suggest a next-best-action — and selects the relevant tools and retrieval scope. Keeping the loop bounded and observable matters more than maximal autonomy: every step is logged so the team can inspect what data was read, what was drafted, and why.", "Grounding is supplied by RAG over product and deal data plus direct CRM function calls. Product specs, pricing rules, security documentation, and battlecards live in a retrieval index; live account state — open opportunities, contacts, recent activity, stage — comes from CRM reads. The agent must cite or attach the source for any factual claim about a product or price, and guardrails reject outputs that assert unverifiable specifics. This is the main defense against fabricated features or numbers leaking into customer communication.", "Outbound actions are gated. The agent drafts emails, follow-ups, and meeting invites into a review surface; nothing is sent, and no irreversible CRM write to a customer-visible field happens, until the rep approves. Internal, low-risk writes (logging an internal note, updating a private next-step) can run with lighter review. Observability via LangSmith or Langfuse traces each run end to end, and semantic caching reuses account-research and product-answer results to cut latency and cost on repeated questions." ], "flow": [ "1. The rep makes a request (\"prep me for the Acme renewal call\") and the router classifies intent and selects the tools and retrieval scope.", "2. The agent reads live account state from CRM via function calls — open opportunities, contacts, stage, recent activity — to ground its reasoning in the real deal.", "3. It retrieves supporting product and deal knowledge through RAG: specs, pricing rules, security docs, and battlecards relevant to the account.", "4. The agent drafts the requested artifact (brief, email, follow-up, next-best-action) with citations or attached sources for every product or pricing claim.", "5. Guardrails check the draft for unverifiable claims, sensitive data, and policy violations; outbound drafts route to the human-approval gate for rep review and edits.", "6. On approval the action executes — email sent, meeting scheduled, activity logged to CRM — and the full run is traced in observability for later audit and evaluation." ], "components": [ "Orchestration loop with intent router", "CRM integration via function calling (reads and writes)", "RAG index over product and deal knowledge", "Email and calendar tools", "Guardrails and claim-verification layer", "Human-approval gate for outbound actions", "Observability and semantic caching" ], "referenceScenario": { "context": "A mid-market B2B software vendor equips its sales team with a copilot to reduce administrative load and improve the quality of account research and outreach. This is an illustrative, vendor-neutral blueprint, not a description of a specific deployment.", "scenario": "Reps ask the copilot to prepare meeting briefs, draft renewal and prospecting emails, summarize account history, log calls, and recommend next-best-actions. The copilot grounds every artifact in CRM state and the product knowledge base, and routes all customer-facing drafts to the rep for approval before sending.", "technology": "An orchestration loop calls the CRM through function calling, retrieves product and deal data via RAG, and uses email and calendar tools. Guardrails verify product and pricing claims, a human-approval gate fronts outbound actions, and LangSmith or Langfuse provide tracing with semantic caching over repeated research.", "load": "Assume a few hundred reps issuing tens of requests each per day, with bursts around quarter-end. Research and drafting requests dominate; outbound sends are comparatively rare because each passes through human review.", "results": "All figures here are reference targets to size and instrument the system, not guarantees: teams should expect to measure their own outcomes on their own data. Plausible targets include reduced time spent on pre-call research and CRM logging, faster first-draft turnaround on outreach, and improved data hygiene — each to be validated against a baseline before and after rollout." }, "benefits": [ "Reps spend less time on administrative work — research, logging, and drafting — and more time in live conversations.", "Outreach and briefs are grounded in the company's real CRM and product data, improving relevance and consistency.", "The human-approval gate keeps reps accountable for every customer-facing message while still accelerating their workflow.", "Observability and tracing make the system auditable, so the team can inspect what was read, drafted, and sent." ], "risks": [ "Hallucinated product features or pricing can leak into customer communication if grounding and claim verification are weak.", "CRM write access creates the risk of corrupting pipeline data if guardrails or approval gates are misconfigured.", "Over-automation can erode rep judgment and relationships if the copilot is allowed to send without genuine review.", "Sensitive customer and deal data flowing through retrieval and prompts raises privacy and access-control concerns." ], "failureModes": [ "The agent asserts a feature or price that is outdated or simply wrong because retrieval missed the authoritative source.", "Reps rubber-stamp drafts without reading them, turning the approval gate into a formality that ships errors.", "Stale or partial CRM reads cause the agent to brief on a deal stage or contact that no longer reflects reality.", "The orchestration loop over-plans or loops on ambiguous requests, burning tokens and latency without converging." ], "lessons": [ "Separate drafting from sending early; the human-approval gate is the single most important safety control for outbound work.", "Treat product and pricing claims as citation-required: if the source cannot be attached, the claim should not ship.", "Instrument from day one — without tracing you cannot tell whether the copilot helped or just generated more activity.", "Scope CRM writes tightly and reversibly, keeping high-risk, customer-visible changes behind explicit rep confirmation." ], "kpis": [ { "metric": "Time saved per rep on research and logging", "note": "Measure pre-call research and CRM-logging time before and after rollout; good looks like a clear, sustained reduction without data-quality loss." }, { "metric": "Approval-gate edit and rejection rate", "note": "Track how often reps edit or reject drafts; a healthy, non-trivial rate shows reps are genuinely reviewing rather than rubber-stamping." }, { "metric": "Grounding and claim-verification accuracy", "note": "Sample drafts and check product and pricing claims against authoritative sources; good means near-zero unverifiable claims reaching customers." }, { "metric": "Pipeline and conversion impact", "note": "Compare conversion or progression for copilot-assisted versus baseline activity; attribute cautiously and look for honest, durable lift." }, { "metric": "Cost and latency per assisted task", "note": "Track tokens, retrieval calls, and response time per request; semantic caching should hold cost and latency stable as usage grows." } ], "scaling": [ "Cost is driven by retrieval volume and model calls per request; semantic caching of repeated account research and product answers is the main lever to contain it.", "Read-heavy traffic (research, briefs, summaries) scales horizontally and benefits from caching; outbound writes are rarer and bounded by human review.", "Quarter-end and campaign bursts require headroom in retrieval and inference capacity, plus rate limiting so a few heavy users do not starve others.", "As the product catalog and CRM grow, retrieval freshness and index maintenance dominate operational cost more than raw inference." ], "examples": [ "A rep asks for a renewal-call brief; the copilot reads the account from CRM, retrieves the relevant contract and product docs, and drafts talking points with sources.", "After a discovery call, the rep dictates notes; the copilot logs a structured activity to CRM and proposes a follow-up email that the rep edits and approves before sending.", "The copilot scans a rep's book of business and surfaces next-best-actions — accounts gone quiet, expiring contracts, upsell signals — each linked to the CRM record behind it." ], "faqs": [ { "q": "Can the copilot send emails to customers on its own?", "a": "No. By design it only drafts; every customer-facing email, follow-up, or invite passes through a human-approval gate where the rep reviews, edits, and approves before anything is sent." }, { "q": "How do you stop it from inventing product features or prices?", "a": "Factual claims about products or pricing must be grounded in retrieved authoritative sources and carry a citation. Guardrails reject outputs that assert unverifiable specifics, and drafts are sampled to verify accuracy." }, { "q": "How do you measure whether it actually helps?", "a": "Through honest metrics — time saved on research and logging, the approval-gate edit rate, grounding accuracy, and cautiously attributed pipeline impact — compared against a baseline rather than raw activity counts." } ] }, "es": { "name": "Copiloto de Ventas", "summary": "Un copiloto de ventas es un agente que asiste a los representantes de principio a fin: investiga cuentas a partir del CRM y de los datos de producto, redacta correos personalizados y seguimientos, registra actividad, propone próximas mejores acciones y prepara informes para reuniones. Todo se fundamenta en el conocimiento de CRM, oportunidades y producto de la empresa para evitar afirmaciones inventadas sobre funciones o precios. El representante mantiene el control: una compuerta de aprobación humana precede a cualquier acción de salida, de modo que el agente redacta pero nunca envía al cliente por su cuenta. El éxito se mide con honestidad mediante la productividad del representante y el impacto en el pipeline, no con métricas de vanidad.", "keyConcepts": [ "Fundamentación en datos de CRM, oportunidades y producto para que el agente razone sobre el pipeline real del representante y no sobre supuestos genéricos.", "Separación estricta entre redactar y enviar, con una compuerta de aprobación humana en cada acción dirigida al cliente.", "Uso de herramientas mediante llamadas a funciones para leer y escribir registros del CRM, buscar conocimiento de producto y agendar reuniones.", "Medición honesta de la productividad del representante y de los resultados del pipeline en lugar del volumen bruto de correos o tareas registradas." ], "definition": "La arquitectura de copiloto de ventas es un asistente agéntico que fundamenta la investigación de cuentas, la redacción de comunicaciones y el registro de actividad en datos de CRM y producto, manteniendo una compuerta de aprobación del representante antes de que algo llegue al cliente.", "architecture": [ "En el núcleo hay un bucle de orquestación que interpreta la intención del representante, planifica una secuencia corta de llamadas a herramientas y ensambla el contexto. Un enrutador clasifica cada solicitud —investigar una cuenta, redactar un correo, registrar una llamada, preparar un informe o sugerir una próxima mejor acción— y selecciona las herramientas y el alcance de recuperación pertinentes. Mantener el bucle acotado y observable importa más que la máxima autonomía: cada paso se registra para que el equipo pueda inspeccionar qué datos se leyeron, qué se redactó y por qué.", "La fundamentación proviene de RAG sobre datos de producto y oportunidades, además de llamadas directas a funciones del CRM. Las especificaciones de producto, las reglas de precios, la documentación de seguridad y los argumentarios viven en un índice de recuperación; el estado vivo de la cuenta —oportunidades abiertas, contactos, actividad reciente, etapa— proviene de lecturas del CRM. El agente debe citar o adjuntar la fuente de cualquier afirmación factual sobre un producto o precio, y los guardarraíles rechazan salidas que afirmen detalles no verificables. Esta es la principal defensa contra la filtración de funciones o cifras inventadas en la comunicación con el cliente.", "Las acciones de salida están protegidas por una compuerta. El agente redacta correos, seguimientos e invitaciones a reuniones en una superficie de revisión; nada se envía, y no ocurre ninguna escritura irreversible en el CRM sobre un campo visible para el cliente, hasta que el representante apruebe. Las escrituras internas de bajo riesgo (registrar una nota interna, actualizar un próximo paso privado) pueden ejecutarse con revisión más ligera. La observabilidad mediante LangSmith o Langfuse traza cada ejecución de extremo a extremo, y el almacenamiento en caché semántico reutiliza resultados de investigación de cuentas y respuestas de producto para reducir latencia y costo en preguntas repetidas." ], "flow": [ "1. El representante hace una solicitud (\"prepárame para la llamada de renovación de Acme\") y el enrutador clasifica la intención y selecciona las herramientas y el alcance de recuperación.", "2. El agente lee el estado vivo de la cuenta desde el CRM mediante llamadas a funciones —oportunidades abiertas, contactos, etapa, actividad reciente— para fundamentar su razonamiento en la oportunidad real.", "3. Recupera conocimiento de apoyo de producto y oportunidades mediante RAG: especificaciones, reglas de precios, documentos de seguridad y argumentarios relevantes para la cuenta.", "4. El agente redacta el artefacto solicitado (informe, correo, seguimiento, próxima mejor acción) con citas o fuentes adjuntas para cada afirmación sobre producto o precio.", "5. Los guardarraíles revisan el borrador en busca de afirmaciones no verificables, datos sensibles y violaciones de política; los borradores de salida pasan a la compuerta de aprobación humana para revisión y edición del representante.", "6. Tras la aprobación se ejecuta la acción —correo enviado, reunión agendada, actividad registrada en el CRM— y toda la ejecución queda trazada en observabilidad para auditoría y evaluación posteriores." ], "components": [ "Bucle de orquestación con enrutador de intención", "Integración de CRM mediante llamadas a funciones (lecturas y escrituras)", "Índice RAG sobre conocimiento de producto y oportunidades", "Herramientas de correo y calendario", "Capa de guardarraíles y verificación de afirmaciones", "Compuerta de aprobación humana para acciones de salida", "Observabilidad y caché semántico" ], "referenceScenario": { "context": "Un proveedor de software B2B de mercado medio dota a su equipo de ventas con un copiloto para reducir la carga administrativa y mejorar la calidad de la investigación de cuentas y de las comunicaciones. Este es un plano ilustrativo y neutral respecto a proveedores, no la descripción de un despliegue específico.", "scenario": "Los representantes piden al copiloto que prepare informes para reuniones, redacte correos de renovación y prospección, resuma el historial de cuentas, registre llamadas y recomiende próximas mejores acciones. El copiloto fundamenta cada artefacto en el estado del CRM y en la base de conocimiento de producto, y enruta todos los borradores dirigidos al cliente al representante para su aprobación antes de enviarlos.", "technology": "Un bucle de orquestación llama al CRM mediante llamadas a funciones, recupera datos de producto y oportunidades vía RAG y usa herramientas de correo y calendario. Los guardarraíles verifican las afirmaciones de producto y precio, una compuerta de aprobación humana precede a las acciones de salida, y LangSmith o Langfuse aportan trazado con caché semántico sobre la investigación repetida.", "load": "Supongamos unos pocos cientos de representantes que emiten decenas de solicitudes cada uno por día, con picos en el cierre de trimestre. Las solicitudes de investigación y redacción dominan; los envíos de salida son comparativamente raros porque cada uno pasa por revisión humana.", "results": "Todas las cifras aquí son objetivos de referencia para dimensionar e instrumentar el sistema, no garantías: los equipos deben esperar medir sus propios resultados con sus propios datos. Objetivos plausibles incluyen menos tiempo dedicado a la investigación previa a la llamada y al registro en CRM, una entrega más rápida del primer borrador de las comunicaciones y mejor higiene de datos —cada uno a validar contra una línea base antes y después del despliegue." }, "benefits": [ "Los representantes dedican menos tiempo a trabajo administrativo —investigación, registro y redacción— y más a conversaciones en vivo.", "Las comunicaciones y los informes se fundamentan en los datos reales de CRM y producto de la empresa, mejorando la relevancia y la consistencia.", "La compuerta de aprobación humana mantiene a los representantes responsables de cada mensaje dirigido al cliente sin dejar de acelerar su flujo de trabajo.", "La observabilidad y el trazado hacen el sistema auditable, de modo que el equipo puede inspeccionar qué se leyó, redactó y envió." ], "risks": [ "Funciones de producto o precios inventados pueden filtrarse en la comunicación con el cliente si la fundamentación y la verificación de afirmaciones son débiles.", "El acceso de escritura al CRM crea el riesgo de corromper datos del pipeline si los guardarraíles o las compuertas de aprobación están mal configurados.", "El exceso de automatización puede erosionar el criterio y las relaciones del representante si se permite que el copiloto envíe sin una revisión genuina.", "Datos sensibles de clientes y oportunidades que fluyen por la recuperación y los prompts plantean preocupaciones de privacidad y control de acceso." ], "failureModes": [ "El agente afirma una función o un precio desactualizado o sencillamente erróneo porque la recuperación no encontró la fuente autorizada.", "Los representantes aprueban borradores sin leerlos, convirtiendo la compuerta de aprobación en un trámite que despacha errores.", "Lecturas obsoletas o parciales del CRM hacen que el agente informe sobre una etapa de oportunidad o un contacto que ya no refleja la realidad.", "El bucle de orquestación sobreplanifica o entra en bucle ante solicitudes ambiguas, consumiendo tokens y latencia sin converger." ], "lessons": [ "Separa la redacción del envío desde el principio; la compuerta de aprobación humana es el control de seguridad más importante para el trabajo de salida.", "Trata las afirmaciones de producto y precio como de cita obligatoria: si no se puede adjuntar la fuente, la afirmación no debe despacharse.", "Instrumenta desde el primer día; sin trazado no puedes saber si el copiloto ayudó o solo generó más actividad.", "Acota las escrituras al CRM de forma estrecha y reversible, manteniendo los cambios de alto riesgo y visibles para el cliente tras confirmación explícita del representante." ], "kpis": [ { "metric": "Tiempo ahorrado por representante en investigación y registro", "note": "Mide el tiempo de investigación previa a la llamada y de registro en CRM antes y después del despliegue; lo bueno es una reducción clara y sostenida sin pérdida de calidad de datos." }, { "metric": "Tasa de edición y rechazo en la compuerta de aprobación", "note": "Rastrea con qué frecuencia los representantes editan o rechazan borradores; una tasa saludable y no trivial muestra que revisan de verdad en lugar de aprobar por inercia." }, { "metric": "Precisión de fundamentación y verificación de afirmaciones", "note": "Muestrea borradores y compara las afirmaciones de producto y precio con fuentes autorizadas; lo bueno es casi cero afirmaciones no verificables llegando a clientes." }, { "metric": "Impacto en pipeline y conversión", "note": "Compara la conversión o el avance entre la actividad asistida por el copiloto y la línea base; atribuye con cautela y busca un aumento honesto y duradero." }, { "metric": "Costo y latencia por tarea asistida", "note": "Rastrea tokens, llamadas de recuperación y tiempo de respuesta por solicitud; el caché semántico debería mantener estables el costo y la latencia a medida que crece el uso." } ], "scaling": [ "El costo lo impulsan el volumen de recuperación y las llamadas al modelo por solicitud; el caché semántico de la investigación de cuentas y las respuestas de producto repetidas es la principal palanca para contenerlo.", "El tráfico intensivo en lecturas (investigación, informes, resúmenes) escala horizontalmente y se beneficia del caché; las escrituras de salida son más raras y están acotadas por la revisión humana.", "Los picos de cierre de trimestre y de campañas requieren holgura en la capacidad de recuperación e inferencia, además de limitación de tasa para que unos pocos usuarios intensivos no priven a los demás.", "A medida que crecen el catálogo de producto y el CRM, la frescura de la recuperación y el mantenimiento del índice dominan el costo operativo más que la inferencia bruta." ], "examples": [ "Un representante pide un informe para una llamada de renovación; el copiloto lee la cuenta desde el CRM, recupera el contrato y la documentación de producto pertinentes y redacta puntos de conversación con fuentes.", "Tras una llamada de descubrimiento, el representante dicta notas; el copiloto registra una actividad estructurada en el CRM y propone un correo de seguimiento que el representante edita y aprueba antes de enviar.", "El copiloto recorre la cartera de un representante y propone próximas mejores acciones —cuentas que enmudecieron, contratos por vencer, señales de upsell— cada una vinculada al registro del CRM que la respalda." ], "faqs": [ { "q": "¿Puede el copiloto enviar correos a los clientes por su cuenta?", "a": "No. Por diseño solo redacta; cada correo, seguimiento o invitación dirigido al cliente pasa por una compuerta de aprobación humana donde el representante revisa, edita y aprueba antes de que se envíe algo." }, { "q": "¿Cómo se evita que invente funciones o precios de producto?", "a": "Las afirmaciones factuales sobre productos o precios deben fundamentarse en fuentes autorizadas recuperadas y llevar una cita. Los guardarraíles rechazan salidas que afirman detalles no verificables, y los borradores se muestrean para verificar su precisión." }, { "q": "¿Cómo se mide si realmente ayuda?", "a": "Mediante métricas honestas —tiempo ahorrado en investigación y registro, la tasa de edición de la compuerta de aprobación, la precisión de fundamentación y un impacto en pipeline atribuido con cautela— comparadas contra una línea base en lugar de recuentos brutos de actividad." } ] }, "pt": { "name": "Copiloto de Vendas", "summary": "Um copiloto de vendas é um agente que assiste os representantes de ponta a ponta: pesquisa contas a partir do CRM e dos dados de produto, redige mensagens personalizadas e follow-ups, registra atividade, sugere próximas melhores ações e prepara briefings para reuniões. Tudo é fundamentado no conhecimento de CRM, oportunidades e produto da empresa para evitar afirmações inventadas sobre funcionalidades ou preços. O representante mantém o controle: um portão de aprovação humana antecede qualquer ação de saída, de modo que o agente redige mas nunca envia ao cliente por conta própria. O sucesso é medido com honestidade pela produtividade do representante e pelo impacto no pipeline, e não por métricas de vaidade.", "keyConcepts": [ "Fundamentação em dados de CRM, oportunidades e produto para que o agente raciocine sobre o pipeline real do representante, e não sobre suposições genéricas.", "Separação rigorosa entre redigir e enviar, com um portão de aprovação humana em cada ação voltada ao cliente.", "Uso de ferramentas via chamadas de função para ler e gravar registros do CRM, buscar conhecimento de produto e agendar reuniões.", "Medição honesta da produtividade do representante e dos resultados de pipeline em vez do volume bruto de e-mails ou tarefas registradas." ], "definition": "A arquitetura de copiloto de vendas é um assistente agêntico que fundamenta a pesquisa de contas, a redação de mensagens e o registro de atividade em dados de CRM e produto, mantendo um portão de aprovação do representante antes que algo chegue ao cliente.", "architecture": [ "No núcleo está um laço de orquestração que interpreta a intenção do representante, planeja uma sequência curta de chamadas de ferramentas e monta o contexto. Um roteador classifica cada solicitação — pesquisar uma conta, redigir um e-mail, registrar uma ligação, preparar um briefing ou sugerir uma próxima melhor ação — e seleciona as ferramentas e o escopo de recuperação pertinentes. Manter o laço delimitado e observável importa mais do que a autonomia máxima: cada passo é registrado para que a equipe possa inspecionar quais dados foram lidos, o que foi redigido e por quê.", "A fundamentação vem de RAG sobre dados de produto e oportunidades, além de chamadas diretas de função ao CRM. Especificações de produto, regras de preço, documentação de segurança e battlecards vivem em um índice de recuperação; o estado vivo da conta — oportunidades abertas, contatos, atividade recente, estágio — vem de leituras do CRM. O agente deve citar ou anexar a fonte de qualquer afirmação factual sobre um produto ou preço, e as guardrails rejeitam saídas que afirmem detalhes não verificáveis. Essa é a principal defesa contra o vazamento de funcionalidades ou números inventados para a comunicação com o cliente.", "As ações de saída ficam atrás de um portão. O agente redige e-mails, follow-ups e convites de reunião em uma superfície de revisão; nada é enviado, e nenhuma gravação irreversível no CRM em um campo visível ao cliente acontece, até o representante aprovar. Gravações internas de baixo risco (registrar uma nota interna, atualizar um próximo passo privado) podem rodar com revisão mais leve. A observabilidade via LangSmith ou Langfuse rastreia cada execução de ponta a ponta, e o cache semântico reutiliza resultados de pesquisa de conta e respostas de produto para reduzir latência e custo em perguntas repetidas." ], "flow": [ "1. O representante faz uma solicitação (\"me prepare para a ligação de renovação da Acme\") e o roteador classifica a intenção e seleciona as ferramentas e o escopo de recuperação.", "2. O agente lê o estado vivo da conta no CRM via chamadas de função — oportunidades abertas, contatos, estágio, atividade recente — para fundamentar seu raciocínio na oportunidade real.", "3. Ele recupera conhecimento de apoio de produto e oportunidades via RAG: especificações, regras de preço, documentos de segurança e battlecards relevantes para a conta.", "4. O agente redige o artefato solicitado (briefing, e-mail, follow-up, próxima melhor ação) com citações ou fontes anexadas para cada afirmação sobre produto ou preço.", "5. As guardrails verificam o rascunho em busca de afirmações não verificáveis, dados sensíveis e violações de política; os rascunhos de saída seguem para o portão de aprovação humana para revisão e edição do representante.", "6. Após a aprovação, a ação é executada — e-mail enviado, reunião agendada, atividade registrada no CRM — e toda a execução fica rastreada na observabilidade para auditoria e avaliação posteriores." ], "components": [ "Laço de orquestração com roteador de intenção", "Integração de CRM via chamadas de função (leituras e gravações)", "Índice RAG sobre conhecimento de produto e oportunidades", "Ferramentas de e-mail e calendário", "Camada de guardrails e verificação de afirmações", "Portão de aprovação humana para ações de saída", "Observabilidade e cache semântico" ], "referenceScenario": { "context": "Um fornecedor de software B2B de mercado intermediário equipa sua equipe de vendas com um copiloto para reduzir a carga administrativa e melhorar a qualidade da pesquisa de contas e das mensagens. Este é um blueprint ilustrativo e neutro em relação a fornecedores, não a descrição de uma implantação específica.", "scenario": "Os representantes pedem ao copiloto para preparar briefings de reunião, redigir e-mails de renovação e prospecção, resumir o histórico de contas, registrar ligações e recomendar próximas melhores ações. O copiloto fundamenta cada artefato no estado do CRM e na base de conhecimento de produto, e encaminha todos os rascunhos voltados ao cliente ao representante para aprovação antes do envio.", "technology": "Um laço de orquestração chama o CRM via chamadas de função, recupera dados de produto e oportunidades via RAG e usa ferramentas de e-mail e calendário. As guardrails verificam afirmações de produto e preço, um portão de aprovação humana antecede as ações de saída, e LangSmith ou Langfuse fornecem rastreamento com cache semântico sobre a pesquisa repetida.", "load": "Suponha algumas centenas de representantes emitindo dezenas de solicitações cada por dia, com picos no fechamento de trimestre. As solicitações de pesquisa e redação dominam; os envios de saída são comparativamente raros porque cada um passa por revisão humana.", "results": "Todos os números aqui são metas de referência para dimensionar e instrumentar o sistema, não garantias: as equipes devem esperar medir seus próprios resultados com seus próprios dados. Metas plausíveis incluem menos tempo gasto em pesquisa pré-ligação e registro no CRM, entrega mais rápida do primeiro rascunho das mensagens e melhor higiene de dados — cada uma a validar contra uma linha de base antes e depois da implantação." }, "benefits": [ "Os representantes gastam menos tempo em trabalho administrativo — pesquisa, registro e redação — e mais em conversas ao vivo.", "As mensagens e os briefings são fundamentados nos dados reais de CRM e produto da empresa, melhorando a relevância e a consistência.", "O portão de aprovação humana mantém os representantes responsáveis por cada mensagem voltada ao cliente sem deixar de acelerar seu fluxo de trabalho.", "A observabilidade e o rastreamento tornam o sistema auditável, de modo que a equipe possa inspecionar o que foi lido, redigido e enviado." ], "risks": [ "Funcionalidades de produto ou preços inventados podem vazar para a comunicação com o cliente se a fundamentação e a verificação de afirmações forem fracas.", "O acesso de gravação ao CRM cria o risco de corromper dados do pipeline se as guardrails ou os portões de aprovação estiverem mal configurados.", "A automação excessiva pode erodir o julgamento e os relacionamentos do representante se for permitido ao copiloto enviar sem revisão genuína.", "Dados sensíveis de clientes e oportunidades que circulam pela recuperação e pelos prompts levantam preocupações de privacidade e controle de acesso." ], "failureModes": [ "O agente afirma uma funcionalidade ou um preço desatualizado ou simplesmente errado porque a recuperação não encontrou a fonte autorizada.", "Os representantes carimbam rascunhos sem lê-los, transformando o portão de aprovação em uma formalidade que despacha erros.", "Leituras desatualizadas ou parciais do CRM fazem o agente informar sobre um estágio de oportunidade ou um contato que já não reflete a realidade.", "O laço de orquestração planeja demais ou entra em loop diante de solicitações ambíguas, consumindo tokens e latência sem convergir." ], "lessons": [ "Separe a redação do envio desde cedo; o portão de aprovação humana é o controle de segurança mais importante para o trabalho de saída.", "Trate afirmações de produto e preço como de citação obrigatória: se a fonte não puder ser anexada, a afirmação não deve ser despachada.", "Instrumente desde o primeiro dia; sem rastreamento você não consegue saber se o copiloto ajudou ou apenas gerou mais atividade.", "Delimite as gravações no CRM de forma estreita e reversível, mantendo mudanças de alto risco e visíveis ao cliente atrás de confirmação explícita do representante." ], "kpis": [ { "metric": "Tempo economizado por representante em pesquisa e registro", "note": "Meça o tempo de pesquisa pré-ligação e de registro no CRM antes e depois da implantação; o bom é uma redução clara e sustentada sem perda de qualidade de dados." }, { "metric": "Taxa de edição e rejeição no portão de aprovação", "note": "Acompanhe com que frequência os representantes editam ou rejeitam rascunhos; uma taxa saudável e não trivial mostra que eles revisam de fato em vez de carimbar." }, { "metric": "Precisão de fundamentação e verificação de afirmações", "note": "Amostre rascunhos e compare as afirmações de produto e preço com fontes autorizadas; o bom é quase zero afirmações não verificáveis chegando aos clientes." }, { "metric": "Impacto em pipeline e conversão", "note": "Compare a conversão ou o avanço entre a atividade assistida pelo copiloto e a linha de base; atribua com cautela e busque um ganho honesto e duradouro." }, { "metric": "Custo e latência por tarefa assistida", "note": "Acompanhe tokens, chamadas de recuperação e tempo de resposta por solicitação; o cache semântico deve manter custo e latência estáveis à medida que o uso cresce." } ], "scaling": [ "O custo é impulsionado pelo volume de recuperação e pelas chamadas ao modelo por solicitação; o cache semântico da pesquisa de contas e das respostas de produto repetidas é a principal alavanca para contê-lo.", "O tráfego intensivo em leituras (pesquisa, briefings, resumos) escala horizontalmente e se beneficia do cache; as gravações de saída são mais raras e delimitadas pela revisão humana.", "Os picos de fechamento de trimestre e de campanhas exigem folga na capacidade de recuperação e inferência, além de limitação de taxa para que poucos usuários intensivos não privem os demais.", "À medida que o catálogo de produto e o CRM crescem, a atualidade da recuperação e a manutenção do índice dominam o custo operacional mais do que a inferência bruta." ], "examples": [ "Um representante pede um briefing para uma ligação de renovação; o copiloto lê a conta no CRM, recupera o contrato e a documentação de produto pertinentes e redige pontos de conversa com fontes.", "Após uma ligação de descoberta, o representante dita notas; o copiloto registra uma atividade estruturada no CRM e propõe um e-mail de follow-up que o representante edita e aprova antes de enviar.", "O copiloto varre a carteira de um representante e sugere próximas melhores ações — contas que silenciaram, contratos a vencer, sinais de upsell — cada uma vinculada ao registro do CRM que a embasa." ], "faqs": [ { "q": "O copiloto pode enviar e-mails aos clientes por conta própria?", "a": "Não. Por design ele apenas redige; cada e-mail, follow-up ou convite voltado ao cliente passa por um portão de aprovação humana onde o representante revisa, edita e aprova antes que algo seja enviado." }, { "q": "Como evitar que ele invente funcionalidades ou preços de produto?", "a": "Afirmações factuais sobre produtos ou preços devem ser fundamentadas em fontes autorizadas recuperadas e levar uma citação. As guardrails rejeitam saídas que afirmam detalhes não verificáveis, e os rascunhos são amostrados para verificar a precisão." }, { "q": "Como medir se ele realmente ajuda?", "a": "Por meio de métricas honestas — tempo economizado em pesquisa e registro, a taxa de edição do portão de aprovação, a precisão de fundamentação e um impacto em pipeline atribuído com cautela — comparadas contra uma linha de base em vez de contagens brutas de atividade." } ] }, "fr": { "name": "Sales Copilot", "summary": "Un copilote de vente (sales copilot) est un agent qui assiste les commerciaux de bout en bout : il effectue des recherches sur les comptes à partir du CRM et des données produits, rédige des messages de prospection et de suivi personnalisés, consigne l'activité, suggère les meilleures actions suivantes et prépare les synthèses de réunion. Tout est ancré dans le CRM, les opportunités et la base de connaissances produits de l'entreprise afin d'éviter les hallucinations concernant les fonctionnalités ou les tarifs. Le commercial garde le contrôle : une étape d'approbation humaine précède toute action sortante, de sorte que l'agent rédige mais n'envoie jamais de message de lui-même. Le succès est mesuré de manière objective à travers la productivité des commerciaux et l'impact sur le pipeline, et non par des indicateurs d'activité superficiels.", "keyConcepts": [ "Ancrage dans le CRM, les opportunités et les données produits pour que l'agent raisonne sur le pipeline réel du commercial plutôt que sur des hypothèses génériques.", "Une séparation stricte entre la rédaction et l'envoi, avec une étape d'approbation humaine pour chaque action destinée aux clients.", "L'utilisation d'outils via l'appel de fonctions (function calling) pour lire et écrire des enregistrements CRM, effectuer des recherches dans la base de connaissances produits et planifier des réunions.", "Une mesure objective de la productivité des commerciaux et des résultats du pipeline, plutôt que le simple volume brut d'e-mails ou de tâches consignées." ], "definition": "L'architecture du copilote de vente est un assistant agentique qui ancre la recherche sur les comptes, la rédaction des messages de prospection et la consignation des activités dans le CRM et les données produits, tout en maintenant une étape d'approbation par le commercial avant toute interaction avec le client.", "architecture": [ "Au cœur du système se trouve une boucle d'orchestration qui interprète l'intention du commercial, planifie une courte séquence d'appels d'outils et assemble le contexte. Un routeur classifie chaque demande — rechercher un compte, rédiger un e-mail, consigner un appel, préparer une synthèse ou suggérer la meilleure action suivante — et sélectionne les outils et le périmètre de récupération appropriés. Maintenir cette boucle délimitée et observable est plus important qu'une autonomie maximale : chaque étape est consignée afin que l'équipe puisse inspecter quelles données ont été lues, ce qui a été rédigé et pourquoi.", "L'ancrage est assuré par du RAG sur les données produits et d'opportunités, ainsi que par des appels directs de fonctions CRM. Les spécifications produits, les règles de tarification, la documentation de sécurité et les battlecards résident dans un index de récupération ; l'état du compte en temps réel — opportunités en cours, contacts, activité récente, étape — provient des lectures du CRM. L'agent doit citer ou joindre la source de toute affirmation factuelle concernant un produit ou un prix, et des garde-fous rejettent les résultats qui avancent des détails invérifiables. C'est la principale défense contre l'apparition de fonctionnalités ou de chiffres inventés dans les communications clients.", "Les actions sortantes sont contrôlées. L'agent rédige des e-mails, des suivis et des invitations à des réunions dans une interface de révision ; rien n'est envoyé, et aucune écriture CRM irréversible sur un champ visible par le client ne se produit tant que le commercial n'a pas validé. Les écritures internes à faible risque (consigner une note interne, mettre à jour une étape suivante privée) peuvent être exécutées avec une révision plus légère. L'observabilité via LangSmith ou Langfuse trace chaque exécution de bout en bout, et la mise en cache sémantique réutilise les résultats des recherches de comptes et des réponses produits pour réduire la latence et les coûts lors de questions répétées." ], "flow": [ "1. Le commercial formule une demande (« prépare-moi pour l'appel de renouvellement d'Acme ») et le routeur classifie l'intention puis sélectionne les outils et le périmètre de récupération.", "2. L'agent lit l'état du compte en temps réel dans le CRM via des appels de fonctions — opportunités en cours, contacts, étape, activité récente — afin d'ancrer son raisonnement dans la réalité du dossier.", "3. Il récupère les connaissances de support sur les produits et les opportunités via RAG : spécifications, règles de tarification, documents de sécurité et battlecards pertinentes pour le compte.", "4. L'agent rédige le livrable demandé (synthèse, e-mail, suivi, meilleure action suivante) avec des citations ou des sources jointes pour chaque affirmation concernant les produits ou les tarifs.", "5. Des garde-fous vérifient que le brouillon ne contient pas d'affirmations invérifiables, de données sensibles ou de violations de politiques ; les brouillons sortants sont acheminés vers l'étape d'approbation humaine pour révision et modification par le commercial.", "6. Une fois l'approbation obtenue, l'action s'exécute — e-mail envoyé, réunion planifiée, activité consignée dans le CRM — et l'exécution complète est tracée dans le système d'observabilité pour audit et évaluation ultérieurs." ], "components": [ "Boucle d'orchestration avec routeur d'intention", "Intégration CRM via appel de fonctions (lectures et écritures)", "Index RAG sur la connaissance des produits et des opportunités", "Outils de messagerie et d'agenda", "Garde-fous et couche de vérification des affirmations", "Étape d'approbation humaine pour les actions sortantes", "Observabilité et mise en cache sémantique" ], "referenceScenario": { "context": "Un éditeur de logiciels B2B du mid-market équipe son équipe commerciale d'un copilote afin de réduire la charge administrative et d'améliorer la qualité de la recherche sur les comptes et de la prospection. Il s'agit d'un modèle illustratif et neutre vis-à-vis des fournisseurs, et non de la description d'un déploiement spécifique.", "scenario": "Les commerciaux demandent au copilote de préparer des synthèses de réunion, de rédiger des e-mails de renouvellement et de prospection, de synthétiser l'historique des comptes, de consigner des appels et de recommander les meilleures actions suivantes. Le copilote ancre chaque livrable dans l'état du CRM et la base de connaissances produits, et achemine tous les brouillons destinés aux clients vers le commercial pour approbation avant envoi.", "technology": "Une boucle d'orchestration appelle le CRM via l'appel de fonctions, récupère les données produits et d'opportunités via RAG, et utilise des outils de messagerie et d'agenda. Des garde-fous vérifient les affirmations sur les produits et les tarifs, une étape d'approbation humaine précède les actions sortantes, et LangSmith ou Langfuse assurent le traçage avec mise en cache sémantique pour les recherches répétées.", "load": "Hypothèse : quelques centaines de commerciaux effectuant chacun des dizaines de requêtes par jour, avec des pics en fin de trimestre. Les demandes de recherche et de rédaction prédominent ; les envois sortants sont comparativement rares car chacun d'eux fait l'objet d'une révision humaine.", "results": "Tous les chiffres présentés ici sont des cibles de référence pour dimensionner et outiller le système, et non des garanties : les équipes doivent s'attendre à mesurer leurs propres résultats sur leurs propres données. Les cibles plausibles incluent une réduction du temps consacré à la recherche avant appel et à la consignation CRM, un délai d'exécution plus rapide pour le premier jet des messages de prospection, et une meilleure hygiène des données — chacun de ces points devant être validé par rapport à une référence avant et après le déploiement." }, "benefits": [ "Les commerciaux passent moins de temps sur les tâches administratives — recherche, consignation et rédaction — et plus de temps en conversations directes.", "La prospection et les synthèses de réunion sont ancrées dans les données réelles du CRM et des produits de l'entreprise, ce qui améliore la pertinence et la cohérence.", "L'étape d'approbation humaine responsabilise les commerciaux pour chaque message destiné aux clients tout en accélérant leur flux de travail.", "L'observabilité et le traçage rendent le système auditable, permettant à l'équipe d'inspecter ce qui a été lu, rédigé et envoyé." ], "risks": [ "Des fonctionnalités de produits ou des tarifs hallucinés peuvent s'immiscer dans les communications clients si l'ancrage et la vérification des affirmations sont insuffisants.", "L'accès en écriture au CRM présente un risque de corruption des données du pipeline si les garde-fous ou les étapes d'approbation sont mal configurés.", "Une automatisation excessive peut altérer le jugement des commerciaux et nuire aux relations si le copilote est autorisé à envoyer des messages sans révision réelle.", "Le flux de données sensibles sur les clients et les opportunités à travers la récupération et les prompts soulève des préoccupations en matière de confidentialité et de contrôle d'accès." ], "failureModes": [ "L'agent affirme une fonctionnalité ou un prix obsolète ou tout simplement erroné parce que la récupération a manqué la source faisant autorité.", "Les commerciaux valident aveuglément les brouillons sans les lire, transformant l'étape d'approbation en une simple formalité qui laisse passer des erreurs.", "Des lectures CRM obsolètes ou partielles amènent l'agent à préparer une synthèse basée sur une étape d'opportunité ou un contact qui ne reflète plus la réalité.", "La boucle d'orchestration planifie de manière excessive ou tourne en boucle sur des requêtes ambiguës, consommant des jetons (tokens) et augmentant la latence sans converger." ], "lessons": [ "Séparez tôt la rédaction de l'envoi ; l'étape d'approbation humaine est le contrôle de sécurité le plus important pour les actions sortantes.", "Exigez des citations pour toute affirmation concernant les produits et les tarifs : si la source ne peut pas être jointe, l'affirmation ne doit pas être envoyée.", "Intégrez l'instrumentation dès le premier jour — sans traçage, vous ne pouvez pas savoir si le copilote a été utile ou s'il a simplement généré plus d'activité.", "Limitez strictement la portée des écritures CRM et rendez-les réversibles, en maintenant les modifications à haut risque et visibles par le client derrière une confirmation explicite du commercial." ], "kpis": [ { "metric": "Temps gagné par commercial sur la recherche et la consignation", "note": "Mesurez le temps de recherche avant appel et de consignation CRM avant et après le déploiement ; un bon résultat se traduit par une réduction claire et durable sans perte de qualité des données." }, { "metric": "Taux de modification et de rejet à l'étape d'approbation", "note": "Suivez la fréquence à laquelle les commerciaux modifient ou rejettent les brouillons ; un taux significatif et sain montre que les commerciaux effectuent une révision réelle plutôt qu'une validation aveugle." }, { "metric": "Précision de l'ancrage et de la vérification des affirmations", "note": "Échantillonnez les brouillons et vérifiez les affirmations sur les produits et les tarifs par rapport aux sources faisant autorité ; un bon résultat signifie que presque aucune affirmation invérifiable ne parvient aux clients." }, { "metric": "Impact sur le pipeline et la conversion", "note": "Comparez la conversion ou la progression des activités assistées par le copilote par rapport à l'activité de référence ; attribuez les résultats avec prudence et recherchez une amélioration réelle et durable." }, { "metric": "Coût et latence par tâche assistée", "note": "Suivez les jetons, les appels de récupération et le temps de réponse par requête ; la mise en cache sémantique doit maintenir les coûts et la latence stables à mesure que l'utilisation augmente." } ], "scaling": [ "Le coût est dicté par le volume de récupération et les appels au modèle par requête ; la mise en cache sémantique des recherches de comptes et des réponses sur les produits répétées est le principal levier pour le contenir.", "Le trafic à forte intensité de lecture (recherches, briefs, résumés) évolue horizontalement et bénéficie de la mise en cache ; les écritures sortantes sont plus rares et limitées par la révision humaine.", "Les pics de fin de trimestre et de campagne nécessitent une marge de manœuvre dans la capacité de récupération et d'inférence, ainsi qu'une limitation du débit pour éviter que quelques utilisateurs intensifs ne privent les autres.", "À mesure que le catalogue de produits et le CRM se développent, la fraîcheur de la récupération et la maintenance de l'index dominent le coût opérationnel plus que l'inférence brute." ], "examples": [ "Un commercial demande un brief pour un appel de renouvellement ; le copilot lit le compte depuis le CRM, récupère le contrat et les documents produits pertinents, et rédige des arguments de discussion avec leurs sources.", "Après un appel de découverte, le commercial dicte des notes ; le copilot enregistre une activité structurée dans le CRM et propose un e-mail de suivi que le commercial modifie et approuve avant l'envoi.", "Le copilot analyse le portefeuille d'un commercial et suggère les meilleures actions suivantes — comptes inactifs, contrats arrivant à échéance, signaux de vente incitative — chacune étant liée à la fiche CRM correspondante." ], "faqs": [ { "q": "Le copilot peut-il envoyer des e-mails aux clients de lui-même ?", "a": "Non. Par conception, il ne fait que rédiger des brouillons ; chaque e-mail, suivi ou invitation destiné aux clients passe par une étape de validation humaine où le commercial examine, modifie et approuve le contenu avant tout envoi." }, { "q": "Comment l'empêcher d'inventer des fonctionnalités de produit ou des prix ?", "a": "Les affirmations factuelles sur les produits ou les prix doivent être ancrées dans des sources de référence récupérées et comporter une citation. Des garde-fous rejettent les résultats qui affirment des détails invérifiables, et des échantillons de brouillons sont contrôlés pour vérifier leur exactitude." }, { "q": "Comment mesurez-vous s'il apporte une aide réelle ?", "a": "Grâce à des indicateurs fiables — temps gagné sur la recherche et la saisie, taux de modification lors de la validation, précision de l'ancrage et impact sur le pipeline attribué avec prudence — comparés à une référence plutôt qu'à de simples volumes d'activité." } ] }, "de": { "name": "Sales Copilot", "summary": "Ein Sales Copilot ist ein Agent, der Vertriebsmitarbeiter End-to-End unterstützt: Er recherchiert Accounts aus CRM- und Produktdaten, entwirft personalisierte Kundenansprachen und Follow-ups, protokolliert Aktivitäten, schlägt Next-Best-Actions vor und bereitet Meeting-Briefings vor. Alles basiert auf dem CRM-, Deal- und Produktwissen des Unternehmens (Grounding), um halluzinierte Behauptungen über Funktionen oder Preise zu vermeiden. Der Vertriebsmitarbeiter behält die Kontrolle: Jede ausgehende Aktion erfordert eine menschliche Freigabe (Human-Approval Gate), sodass der Agent zwar Entwürfe erstellt, aber niemals selbstständig Nachrichten an Kunden sendet. Der Erfolg wird ehrlich an der Produktivität der Mitarbeiter und dem Einfluss auf die Pipeline gemessen, nicht an oberflächlichen Aktivitätszahlen.", "keyConcepts": [ "Grounding in CRM-, Deal- und Produktdaten, sodass der Agent auf Basis der tatsächlichen Pipeline des Vertriebsmitarbeiters agiert, anstatt generische Annahmen zu treffen.", "Eine strikte Trennung zwischen Entwurf und Versand, mit einer menschlichen Freigabe (Human-Approval Gate) für jede kundengerichtete Aktion.", "Tool-Nutzung via Function Calling zum Lesen und Schreiben von CRM-Einträgen, Durchsuchen von Produktwissen und Planen von Terminen.", "Ehrliche Messung der Produktivität der Vertriebsmitarbeiter und der Pipeline-Ergebnisse anstelle des reinen Volumens an E-Mails oder protokollierten Aufgaben." ], "definition": "Die Sales-Copilot-Architektur ist ein agentenbasierter Assistent, der Account-Recherche, Entwürfe für die Kundenansprache und Aktivitätsprotokollierung auf Basis von CRM- und Produktdaten durchführt (Grounding), während eine Freigabe durch den Vertriebsmitarbeiter vorgeschaltet bleibt, bevor Informationen den Kunden erreichen.", "architecture": [ "Im Zentrum steht ein Orchestration Loop, der die Absicht (Intent) des Vertriebsmitarbeiters interpretiert, eine kurze Sequenz von Tool-Aufrufen plant und den Kontext zusammenstellt. Ein Router klassifiziert jede Anfrage – Account recherchieren, E-Mail entwerfen, Anruf protokollieren, Briefing vorbereiten oder eine Next-Best-Action vorschlagen – und wählt die relevanten Tools sowie den Retrieval-Umfang aus. Den Loop begrenzt und beobachtbar zu halten, ist wichtiger als maximale Autonomie: Jeder Schritt wird protokolliert, damit das Team nachvollziehen kann, welche Daten gelesen, was entworfen wurde und warum.", "Das Grounding erfolgt über RAG auf Produkt- und Deal-Daten sowie direkte CRM-Funktionsaufrufe. Produktspezifikationen, Preisregeln, Sicherheitsdokumentationen und Battlecards befinden sich in einem Retrieval-Index; der Live-Account-Status – offene Opportunities, Kontakte, letzte Aktivitäten, Phase – stammt aus CRM-Abfragen. Der Agent muss für jede sachliche Behauptung über ein Produkt oder einen Preis die Quelle zitieren oder anhängen, und Guardrails weisen Ausgaben zurück, die nicht verifizierbare Details behaupten. Dies ist der wichtigste Schutz davor, dass erfundene Funktionen oder Zahlen in die Kundenkommunikation gelangen.", "Ausgehende Aktionen sind reglementiert. Der Agent erstellt Entwürfe für E-Mails, Follow-ups und Termineinladungen in einer Review-Oberfläche; nichts wird gesendet und es erfolgt kein irreversibler CRM-Schreibvorgang in ein für Kunden sichtbares Feld, bevor der Vertriebsmitarbeiter zustimmt. Interne, risikoarme Schreibvorgänge (Protokollieren einer internen Notiz, Aktualisieren eines privaten nächsten Schritts) können mit einer weniger strengen Prüfung durchgeführt werden. Observability über LangSmith- oder Langfuse-Traces verfolgt jeden Durchlauf End-to-End, und Semantic Caching verwendet Ergebnisse aus Account-Recherchen und Produktantworten wieder, um Latenz und Kosten bei wiederholten Fragen zu senken." ], "flow": [ "1. Der Vertriebsmitarbeiter stellt eine Anfrage („Bereite mich auf das Acme-Verlängerungsgespräch vor“) und der Router klassifiziert den Intent und wählt die Tools sowie den Retrieval-Umfang aus.", "2. Der Agent liest den Live-Account-Status über Funktionsaufrufe aus dem CRM – offene Opportunities, Kontakte, Phase, letzte Aktivitäten –, um seine Argumentation auf dem tatsächlichen Deal zu basieren.", "3. Er ruft unterstützendes Produkt- und Deal-Wissen über RAG ab: Spezifikationen, Preisregeln, Sicherheitsdokumente und Battlecards, die für den Account relevant sind.", "4. Der Agent entwirft das angeforderte Artefakt (Briefing, E-Mail, Follow-up, Next-Best-Action) mit Quellenangaben oder angehängten Quellen für jede Produkt- oder Preisbehauptung.", "5. Guardrails prüfen den Entwurf auf nicht verifizierbare Behauptungen, sensible Daten und Richtlinienverstöße; ausgehende Entwürfe werden zur Überprüfung und Bearbeitung durch den Vertriebsmitarbeiter an das Human-Approval Gate weitergeleitet.", "6. Nach der Freigabe wird die Aktion ausgeführt – E-Mail gesendet, Termin geplant, Aktivität im CRM protokolliert – und der gesamte Durchlauf wird zur späteren Überprüfung und Evaluierung in der Observability-Plattform nachverfolgt (Traced)." ], "components": [ "Orchestration Loop mit Intent-Router", "CRM-Integration via Function Calling (Lesen und Schreiben)", "RAG-Index über Produkt- und Deal-Wissen", "E-Mail- und Kalender-Tools", "Guardrails und Layer zur Überprüfung von Behauptungen", "Human-Approval Gate für ausgehende Aktionen", "Observability und Semantic Caching" ], "referenceScenario": { "context": "Ein mittelständischer B2B-Softwareanbieter stattet sein Vertriebsteam mit einem Copilot aus, um den administrativen Aufwand zu reduzieren und die Qualität von Account-Recherche und Kundenansprache zu verbessern. Dies ist ein illustrativer, herstellerneutraler Entwurf, keine Beschreibung einer spezifischen Bereitstellung.", "scenario": "Vertriebsmitarbeiter bitten den Copilot, Meeting-Briefings vorzubereiten, Entwürfe für Verlängerungs- und Akquise-E-Mails zu erstellen, die Account-Historie zusammenzufassen, Anrufe zu protokollieren und Next-Best-Actions zu empfehlen. Der Copilot basiert jedes Artefakt auf dem CRM-Status und der Produkt-Wissensdatenbank (Grounding) und leitet alle kundengerichteten Entwürfe vor dem Senden zur Freigabe an den Mitarbeiter weiter.", "technology": "Ein Orchestration Loop ruft das CRM über Function Calling auf, ruft Produkt- und Deal-Daten über RAG ab und nutzt E-Mail- sowie Kalender-Tools. Guardrails verifizieren Produkt- und Preisbehauptungen, ein Human-Approval Gate sichert ausgehende Aktionen ab, und LangSmith oder Langfuse bieten Tracing mit Semantic Caching bei wiederholten Recherchen.", "load": "Angenommen werden einige hundert Vertriebsmitarbeiter, die jeweils Dutzende von Anfragen pro Tag stellen, mit Spitzenwerten zum Quartalsende. Anfragen zur Recherche und Entwurfserstellung dominieren; das tatsächliche Senden von Nachrichten ist vergleichsweise selten, da jede Nachricht eine menschliche Prüfung durchläuft.", "results": "Alle hier genannten Zahlen sind Richtwerte zur Dimensionierung und Instrumentierung des Systems, keine Garantien: Teams sollten ihre eigenen Ergebnisse anhand ihrer eigenen Daten messen. Plausible Ziele sind eine Reduzierung der Zeit für die Vorbereitung von Gesprächen und die CRM-Protokollierung, eine schnellere Erstellung erster Entwürfe für die Kundenansprache sowie eine verbesserte Datenhygiene – jeweils zu validieren im Vergleich zu einer Baseline vor und nach dem Rollout." }, "benefits": [ "Vertriebsmitarbeiter verbringen weniger Zeit mit administrativen Aufgaben – Recherche, Protokollierung und Entwurfserstellung – und mehr Zeit in persönlichen Gesprächen.", "Kundenansprachen und Briefings basieren auf den echten CRM- und Produktdaten des Unternehmens (Grounding), was Relevanz und Konsistenz verbessert.", "Das Human-Approval Gate stellt sicher, dass die Vertriebsmitarbeiter für jede kundengerichtete Nachricht verantwortlich bleiben, während ihr Workflow dennoch beschleunigt wird.", "Observability und Tracing machen das System auditierbar, sodass das Team überprüfen kann, was gelesen, entworfen und gesendet wurde." ], "risks": [ "Halluzinierte Produktfunktionen oder Preise können in die Kundenkommunikation gelangen, wenn Grounding und die Überprüfung von Behauptungen schwach ausgeprägt sind.", "Der CRM-Schreibzugriff birgt das Risiko, Pipeline-Daten zu beschädigen, wenn Guardrails oder Approval Gates falsch konfiguriert sind.", "Überautomatisierung kann das Urteilsvermögen der Mitarbeiter und die Kundenbeziehungen beeinträchtigen, wenn der Copilot ohne echte Prüfung senden darf.", "Sensible Kunden- und Deal-Daten, die durch Retrieval und Prompts fließen, werfen Fragen zum Datenschutz und zur Zugriffskontrolle auf." ], "failureModes": [ "Der Agent behauptet eine Funktion oder einen Preis, die veraltet oder schlichtweg falsch sind, weil das Retrieval die maßgebliche Quelle verfehlt hat.", "Vertriebsmitarbeiter winken Entwürfe ungeprüft durch, wodurch das Approval Gate zu einer reinen Formalität wird, die Fehler durchgehen lässt.", "Veraltete oder unvollständige CRM-Abfragen führen dazu, dass der Agent Briefings zu einer Deal-Phase oder einem Kontakt erstellt, die nicht mehr der Realität entsprechen.", "Der Orchestration Loop plant zu komplex oder gerät bei mehrdeutigen Anfragen in eine Endlosschleife, was Tokens und Latenz verbraucht, ohne zu einem Ergebnis zu führen." ], "lessons": [ "Trennen Sie Entwurf und Versand frühzeitig; das Human-Approval Gate ist die wichtigste Sicherheitsmaßnahme für ausgehende Aktivitäten.", "Behandeln Sie Produkt- und Preisbehauptungen als zitierpflichtig: Wenn die Quelle nicht angehängt werden kann, sollte die Behauptung nicht gesendet werden.", "Instrumentieren Sie das System vom ersten Tag an – ohne Tracing können Sie nicht feststellen, ob der Copilot geholfen oder nur mehr Aktivität generiert hat.", "Grenzen Sie CRM-Schreibvorgänge eng und reversibel ein, und halten Sie risikoreiche, für Kunden sichtbare Änderungen hinter einer expliziten Bestätigung durch den Mitarbeiter zurück." ], "kpis": [ { "metric": "Zeitersparnis pro Vertriebsmitarbeiter bei Recherche und Protokollierung", "note": "Messen Sie die Zeit für die Vorbereitung von Gesprächen und die CRM-Protokollierung vor und nach dem Rollout; ein gutes Ergebnis zeigt sich in einer deutlichen, nachhaltigen Reduzierung ohne Einbußen bei der Datenqualität." }, { "metric": "Bearbeitungs- und Ablehnungsrate am Approval Gate", "note": "Verfolgen Sie, wie oft Vertriebsmitarbeiter Entwürfe bearbeiten oder ablehnen; eine gesunde, spürbare Rate zeigt, dass die Mitarbeiter die Entwürfe tatsächlich prüfen, anstatt sie nur durchzuwinken." }, { "metric": "Genauigkeit von Grounding und Behauptungsüberprüfung", "note": "Prüfen Sie stichprobenartig Entwürfe und vergleichen Sie Produkt- und Preisbehauptungen mit maßgeblichen Quellen; ein gutes Ergebnis bedeutet, dass nahezu keine nicht verifizierbaren Behauptungen den Kunden erreichen." }, { "metric": "Einfluss auf Pipeline und Conversion", "note": "Vergleichen Sie die Conversion oder den Fortschritt von Copilot-unterstützten Aktivitäten mit der Baseline; ordnen Sie die Effekte vorsichtig zu und achten Sie auf eine ehrliche, nachhaltige Steigerung." }, { "metric": "Kosten und Latenz pro unterstützter Aufgabe", "note": "Erfassen Sie Token, Retrieval-Aufrufe und die Antwortzeit pro Anfrage; semantisches Caching sollte Kosten und Latenz bei steigender Nutzung stabil halten." } ], "scaling": [ "Die Kosten werden durch das Retrieval-Volumen und die Modellaufrufe pro Anfrage bestimmt; semantisches Caching von wiederholten Account-Recherchen und Produktantworten ist der wichtigste Hebel, um sie einzudämmen.", "Leseintensiver Traffic (Recherchen, Briefings, Zusammenfassungen) skaliert horizontal und profitiert von Caching; ausgehende Schreibvorgänge sind seltener und durch menschliche Freigabe begrenzt.", "Spitzenzeiten zum Quartalsende und bei Kampagnen erfordern Puffer bei der Retrieval- und Inferenzkapazität sowie ein Rate Limiting, damit einige wenige Power-User andere nicht blockieren.", "Mit dem Wachstum des Produktkatalogs und des CRMs dominieren die Aktualität des Retrievals und die Indexpflege die Betriebskosten stärker als die reine Inferenz." ], "examples": [ "Ein Vertriebsmitarbeiter bittet um ein Briefing für ein Verlängerungsgespräch; der Copilot liest den Account aus dem CRM, ruft die relevanten Vertrags- und Produktdokumente ab und entwirft Gesprächspunkte mit Quellenangaben.", "Nach einem Erstgespräch diktiert der Vertriebsmitarbeiter Notizen; der Copilot protokolliert eine strukturierte Aktivität im CRM und schlägt eine Follow-up-E-Mail vor, die der Mitarbeiter vor dem Versenden bearbeitet und freigibt.", "Der Copilot scannt das Kundenportfolio eines Vertriebsmitarbeiters und schlägt Next-Best-Actions vor – inaktive Accounts, auslaufende Verträge, Upsell-Signale –, jeweils verknüpft mit dem dahinterstehenden CRM-Datensatz." ], "faqs": [ { "q": "Kann der Copilot selbstständig E-Mails an Kunden senden?", "a": "Nein. Konzeptionell erstellt er nur Entwürfe; jede kundengerichtete E-Mail, jedes Follow-up oder jede Einladung durchläuft eine menschliche Freigabestufe, bei der der Vertriebsmitarbeiter den Entwurf prüft, bearbeitet und freigibt, bevor etwas gesendet wird." }, { "q": "Wie verhindern Sie, dass er Produktfunktionen oder Preise erfindet?", "a": "Faktische Behauptungen über Produkte oder Preise müssen in abgerufenen, maßgeblichen Quellen verankert sein (Grounding) und eine Quellenangabe enthalten. Guardrails weisen Ausgaben zurück, die nicht verifizierbare Details behaupten, und Entwürfe werden stichprobenartig auf ihre Richtigkeit überprüft." }, { "q": "Wie messen Sie, ob er tatsächlich hilft?", "a": "Durch ehrliche Metriken – Zeitersparnis bei Recherche und Protokollierung, die Bearbeitungsquote in der Freigabestufe, Grounding-Genauigkeit und vorsichtig zugeschriebene Pipeline-Effekte – im Vergleich zu einer Baseline statt zu reinen Aktivitätszahlen." } ] }, "ja": { "name": "Sales Copilot", "summary": "セールスコパイロット（Sales Copilot）は、営業担当者をエンドツーエンドで支援するエージェントです。CRMや製品データからアカウントを調査し、パーソナライズされたアウトリーチやフォローアップのドラフトを作成し、アクティビティを記録し、ネクストベストアクションを提示し、ミーティングブリーフを準備します。機能や価格に関するハルシネーション（事実に基づかない主張）を防ぐため、すべてが自社のCRM、ディール、製品ナレッジにグラウンディング（根拠付け）されます。営業担当者が常にコントロールを保持します。すべてのアウトバウンドアクションの手前に人間の承認ゲートが配置されているため、エージェントはドラフトを作成するだけで、自律的に顧客に送信することはありません。成功は、見せかけのアクティビティ数ではなく、営業担当者の生産性とパイプラインへの影響を通じて誠実に測定されます。", "keyConcepts": [ "CRM、ディール、製品データへのグラウンディング。これにより、エージェントは一般的な仮定ではなく、営業担当者の実際のパイプラインに基づいて推論を行います。", "ドラフト作成と送信の厳格な分離。顧客向けのアクションすべてに人間の承認ゲートを設けます。", "ファンクションコーリング（function calling）を介したツール利用。CRMレコードの読み書き、製品ナレッジの検索、ミーティングのスケジュール設定を行います。", "メールの総送信数や記録されたタスク数ではなく、営業担当者の生産性とパイプラインの成果を誠実に測定すること。" ], "definition": "セールスコパイロットのアーキテクチャは、アカウント調査、アウトリーチのドラフト作成、アクティビティ記録をCRMおよび製品データにグラウンディングさせつつ、顧客に届くすべてのプロセスの手前に営業担当者の承認ゲートを維持する、エージェント型のアシスタントです。", "architecture": [ "中核となるのは、営業担当者の意図を解釈し、短い一連のツール呼び出しを計画し、コンテキストを組み立てるオーケストレーションループです。ルーターが各リクエスト（アカウントの調査、メールのドラフト作成、通話の記録、ブリーフの準備、ネクストベストアクションの提案など）を分類し、関連するツールと検索範囲を選択します。ループを限定的かつ観察可能に保つことは、最大限の自律性を持たせることよりも重要です。すべてのステップがログに記録されるため、チームはどのデータが読み取られ、何がドラフトされ、それがなぜなのかを検査できます。", "グラウンディングは、製品およびディールデータに対するRAGと、直接的なCRMファンクションコーリングによって提供されます。製品仕様、価格ルール、セキュリティ文書、バトルカードは検索インデックスに格納され、進行中の商談、連絡先、最近のアクティビティ、ステージなどのリアルタイムのアカウント状態はCRMの読み取りから取得されます。エージェントは、製品や価格に関する事実の主張に対して、ソースを引用または添付しなければならず、ガードレールは検証不可能な詳細を主張する出力を拒否します。これは、捏造された機能や数値が顧客とのコミュニケーションに紛れ込むのを防ぐための主要な防御策です。", "アウトバウンドアクションは制限（ゲート）されます。エージェントはメール、フォローアップ、ミーティングの招待をレビュー画面にドラフトします。営業担当者が承認するまで、何も送信されず、顧客に表示されるフィールドへの不可逆的なCRM書き込みも発生しません。内部の低リスクな書き込み（内部メモの記録、非公開の次のステップの更新など）は、より簡易なレビューで実行できます。LangSmithまたはLangfuseによるオブザーバビリティ（可観測性）が各実行をエンドツーエンドでトレースし、セマンティックキャッシュがアカウント調査や製品回答の結果を再利用して、繰り返される質問のレイテンシとコストを削減します。" ], "flow": [ "1. 営業担当者がリクエスト（「Acme社の更新電話の準備をして」など）を行い、ルーターが意図を分類してツールと検索範囲を選択します。", "2. エージェントはファンクションコーリングを介してCRMからリアルタイムのアカウント状態（進行中の商談、連絡先、ステージ、最近のアクティビティなど）を読み取り、実際の取引に推論をグラウンディングさせます。", "3. RAGを通じて、アカウントに関連する製品仕様、価格ルール、セキュリティ文書、バトルカードなどの補足的な製品およびディールナレッジを検索します。", "4. エージェントは、製品や価格に関するすべての主張について引用またはソースを添付した上で、要求された成果物（ブリーフ、メール、フォローアップ、ネクストベストアクション）をドラフトします。", "5. ガードレールがドラフトをチェックし、検証不可能な主張、機密データ、ポリシー違反がないか確認します。アウトバウンドのドラフトは、営業担当者のレビューと編集のために人間の承認ゲートにルーティングされます。", "6. 承認されると、アクション（メール送信、ミーティングのスケジュール設定、CRMへのアクティビティ記録など）が実行され、後日の監査と評価のために実行全体がオブザーバビリティツールでトレースされます。" ], "components": [ "意図ルーターを備えたオーケストレーションループ", "ファンクションコーリングを介したCRM統合（読み取りおよび書き込み）", "製品およびディールナレッジに対するRAGインデックス", "メールおよびカレンダーツール", "ガードレールおよび主張検証レイヤー", "アウトバウンドアクション向けの人間の承認ゲート", "オブザーバビリティおよびセマンティックキャッシュ" ], "referenceScenario": { "context": "中規模市場向けのB2Bソフトウェアベンダーが、管理業務の負荷を軽減し、アカウント調査とアウトリーチの品質を向上させるために、営業チームにコパイロットを導入します。これは説明用のベンダーニュートラルなブループリントであり、特定の展開について説明するものではありません。", "scenario": "営業担当者はコパイロットに対し、ミーティングブリーフの準備、更新や新規開拓メールのドラフト作成、アカウント履歴の要約、通話の記録、ネクストベストアクションの推奨を依頼します。コパイロットはすべての成果物をCRMの状態と製品ナレッジベースにグラウンディングさせ、顧客向けに作成されたすべてのドラフトを送信前に営業担当者にルーティングして承認を求めます。", "technology": "オーケストレーションループがファンクションコーリングを介してCRMを呼び出し、RAGを介して製品およびディールデータを取得し、メールおよびカレンダーツールを使用します。ガードレールが製品や価格に関する主張を検証し、人間の承認ゲートがアウトバウンドアクションの手前に配置され、LangSmithまたはLangfuseがトレースを提供し、繰り返される調査に対してセマンティックキャッシュを適用します。", "load": "数百人の営業担当者がそれぞれ1日に数十件のリクエストを発行し、四半期末付近にバーストが発生すると想定します。調査とドラフト作成のリクエストが大部分を占め、それぞれが人間のレビューを通過するため、アウトバウンドの送信は比較的まれです。", "results": "ここに記載されているすべての数値は、システムの規模決定と計測のための参照ターゲットであり、保証ではありません。チームは独自のデータに基づいて独自の成果を測定する必要があります。妥当なターゲットとしては、通話前の調査やCRMへの記録に費やす時間の削減、アウトリーチの最初のドラフト作成の迅速化、データ衛生状態の改善などが挙げられ、それぞれ導入前後のベースラインと比較して検証されます。" }, "benefits": [ "営業担当者が調査、記録、ドラフト作成などの管理業務に費やす時間が減り、実際の会話により多くの時間を割けるようになります。", "アウトリーチやブリーフが自社の実際のCRMおよび製品データにグラウンディングされるため、関連性と一貫性が向上します。", "人間の承認ゲートにより、営業担当者はワークフローを加速させつつ、顧客向けのすべてのメッセージに対して責任を維持できます。", "オブザーバビリティとトレースによりシステムが監査可能になり、チームは何が読み取られ、ドラフトされ、送信されたかを検査できます。" ], "risks": [ "グラウンディングと主張の検証が不十分な場合、ハルシネーションによる製品機能や価格が顧客とのコミュニケーションに紛れ込む可能性があります。", "ガードレールや承認ゲートの設定が誤っている場合、CRMへの書き込みアクセスによってパイプラインデータが破損するリスクが生じます。", "コパイロットが実質的なレビューなしに送信することを許可してしまうと、過剰な自動化によって営業担当者の判断力や関係性が損なわれる可能性があります。", "検索やプロンプトを流れる機密性の高い顧客データやディールデータは、プライバシーやアクセス制御に関する懸念を引き起こします。" ], "failureModes": [ "検索が信頼できる情報源を見落としたため、エージェントが古い、または完全に誤った機能や価格を主張してしまう。", "営業担当者がドラフトを読まずに形式的に承認（ラバースタンプ）してしまい、承認ゲートが形骸化してエラーがそのまま送信されてしまう。", "古くなった、または不完全なCRMの読み取りにより、エージェントが現状を反映していないディールステージや連絡先に基づいてブリーフを作成してしまう。", "オーケストレーションループが過剰な計画を立てたり、曖昧なリクエストに対してループしたりして、収束しないままトークンを消費し、レイテンシを悪化させてしまう。" ], "lessons": [ "早い段階でドラフト作成と送信を分離すること。人間の承認ゲートは、アウトバウンド業務における最も重要な単一の安全管理策です。", "製品や価格に関する主張は「引用必須」として扱うこと。ソースを添付できない場合は、その主張を送信すべきではありません。", "初日から計測環境を整えること。トレースがなければ、コパイロットが役に立ったのか、それとも単にアクティビティを増やしただけなのかを判断できません。", "CRMへの書き込み範囲を厳格かつ可逆的に制限し、リスクが高く顧客に表示される変更については、営業担当者による明示的な確認を必須とすること。" ], "kpis": [ { "metric": "調査と記録において営業担当者1人あたりが削減できた時間", "note": "導入前後で通話前の調査とCRMへの記録時間を測定します。データの品質を落とすことなく、明確かつ持続的な削減が見られる状態が良好です。" }, { "metric": "承認ゲートでの編集および却下率", "note": "営業担当者がドラフトを編集または却下する頻度を追跡します。一定の健全な割合が維持されていることは、営業担当者が形式的な承認（ラバースタンプ）ではなく、実際にレビューを行っていることを示します。" }, { "metric": "グラウンディングおよび主張検証の正確性", "note": "ドラフトをサンプリングし、製品や価格に関する主張を信頼できる情報源と照合します。検証不可能な主張が顧客に届く割合がほぼゼロである状態が良好です。" }, { "metric": "パイプラインおよびコンバージョンへの影響", "note": "コパイロットが支援したアクティビティとベースラインのアクティビティについて、コンバージョンまたはプログレッション（進捗）を比較します。因果関係の特定は慎重に行い、誠実で持続的な向上を目指します。" }, { "metric": "支援されたタスクあたりのコストとレイテンシ", "note": "リクエストごとのトークン数、リトリーバル呼び出し、および応答時間を追跡します。セマンティックキャッシュにより、利用規模が拡大してもコストとレイテンシを安定して維持する必要があります。" } ], "scaling": [ "コストは、リクエストごとのリトリーバル量とモデル呼び出し回数によって左右されます。繰り返されるアカウント調査や製品回答に対するセマンティックキャッシュの適用が、コストを抑制するための主な手段となります。", "読み取り主体のトラフィック（調査、ブリーフ、要約）は水平方向にスケールし、キャッシュの恩恵を受けます。一方、アウトバウンドの書き込みはより稀であり、人間のレビューによって制限されます。", "四半期末やキャンペーン時のバーストトラフィックには、リトリーバルおよび推論容量の余力に加え、一部のヘビーユーザーが他を圧迫しないようにするためのレート制限が必要です。", "製品カタログやCRMが成長するにつれて、リトリーバルの最新性とインデックスのメンテナンスが、生の推論よりも運用コストの大部分を占めるようになります。" ], "examples": [ "担当者が更新電話用のブリーフを要求すると、コパイロットはCRMからアカウント情報を読み取り、関連する契約書や製品ドキュメントを取得して、情報源付きのトークポイントの下書きを作成します。", "ディスカバリーコールの後、担当者がメモを口述すると、コパイロットは構造化されたアクティビティをCRMに記録し、フォローアップメールを提案します。担当者は送信前にこれを編集し、承認します。", "コパイロットは担当者の担当顧客リストをスキャンし、次の最善のアクション（連絡が途絶えたアカウント、期限切れ間近の契約、アップセルの兆候など）を提示します。それぞれのアクションは、その背景にあるCRMレコードにリンクされています。" ], "faqs": [ { "q": "コパイロットは自律的に顧客へメールを送信できますか？", "a": "いいえ。設計上、コパイロットは下書きを作成するだけです。顧客向けのメール、フォローアップ、または招待はすべて、送信前に担当者が確認、編集、承認を行う「人間の承認ゲート」を通過します。" }, { "q": "製品の機能や価格を捏造するのを防ぐにはどうすればよいですか？", "a": "製品や価格に関する事実の主張は、取得した信頼できる情報源に根ざしている必要があり、引用を含める必要があります。ガードレールによって、検証不可能な詳細を主張する出力は拒否され、下書きは正確性を検証するためにサンプリングされます。" }, { "q": "実際に役立っているかどうかをどのように測定しますか？", "a": "生の活動件数ではなく、基準値（ベースライン）と比較した誠実な指標（調査や記録に費やす時間の削減、承認ゲートでの編集率、グラウンディングの正確性、慎重に帰属させたパイプラインへの影響など）を通じて測定します。" } ] }, "zh": { "name": "Sales Copilot", "summary": "Sales Copilot 是一款端到端辅助销售代表的智能体：它能根据 CRM 和产品数据研究客户，起草个性化的外联和跟进内容，记录活动，提供“下一步最佳行动”建议，并准备会议简报。所有内容都基于公司的 CRM、交易和产品知识，以避免对功能或价格产生幻觉。销售代表始终保持控制权：在执行任何外发操作之前都有人工审批环节，因此智能体只负责起草，绝不会自行向客户发送。成功是通过销售代表的生产力和对销售管线（pipeline）的影响来真实衡量的，而不是通过虚荣的活动数量。", "keyConcepts": [ "基于 CRM、交易和产品数据进行知识植入（grounding），使智能体能够针对销售代表的真实销售管线进行推理，而不是基于通用的假设。", "严格区分起草与发送，对每一项面向客户的操作都设置人工审批环节。", "通过函数调用（function calling）使用工具，以读写 CRM 记录、搜索产品知识并安排会议。", "真实衡量销售代表的生产力和销售管线成果，而不是单纯统计电子邮件数量或记录的任务数。" ], "definition": "Sales Copilot 架构是一种智能体助手，它将客户研究、外联起草和活动记录基于 CRM 和产品数据进行知识植入，同时在任何内容发送给客户之前保留销售代表的审批环节。", "architecture": [ "其核心是一个编排循环，用于解释销售代表的意图、规划简短的工具调用序列并组装上下文。路由器对每个请求进行分类（研究客户、起草电子邮件、记录通话、准备简报或建议下一步最佳行动），并选择相关的工具和检索范围。保持循环的有界性和可观测性比追求最大程度的自主性更重要：每一步都会被记录下来，以便团队可以检查读取了哪些数据、起草了什么内容以及原因。", "知识植入是通过对产品和交易数据进行 RAG（检索增强生成）以及直接的 CRM 函数调用来实现的。产品规格、定价规则、安全文档和竞争分析（battlecards）存在于检索索引中；实时的客户状态（未结商机、联系人、近期活动、阶段）则来自 CRM 读取。智能体必须为任何关于产品或价格的事实性陈述引用或附加来源，且护栏（guardrails）会拒绝断言无法验证的细节的输出。这是防止虚构的功能或数字泄露到客户沟通中的主要防线。", "外发操作受到严格把关。智能体将电子邮件、跟进内容和会议邀请起草到评审界面中；在销售代表批准之前，不会发送任何内容，也不会对客户可见的字段进行任何不可逆的 CRM 写入。内部、低风险的写入（记录内部备注、更新私有下一步骤）可以在较轻的审核下运行。通过 LangSmith 或 Langfuse 实现的可观测性可端到端地追踪每次运行，而语义缓存（semantic caching）则可以复用客户研究和产品解答的结果，从而降低重复问题的延迟和成本。" ], "flow": [ "1. 销售代表提出请求（“帮我准备 Acme 续约会议”），路由器对意图进行分类并选择工具和检索范围。", "2. 智能体通过函数调用从 CRM 读取实时客户状态（未结商机、联系人、阶段、近期活动），以使其推理基于真实的交易情况。", "3. 它通过 RAG 检索支持性的产品和交易知识：与该客户相关的规格、定价规则、安全文档和竞争分析。", "4. 智能体起草请求的产出物（简报、电子邮件、跟进内容、下一步最佳行动），并为每个产品或定价陈述提供引用或附加来源。", "5. 护栏检查草稿中是否存在无法验证的陈述、敏感数据和违反政策的内容；外发草稿将路由到人工审批环节，供销售代表评审和修改。", "6. 批准后执行操作（发送电子邮件、安排会议、将活动记录到 CRM），并且在可观测性系统中追踪完整运行过程，以便日后审计和评估。" ], "components": [ "带有意图路由器的编排循环", "通过函数调用实现的 CRM 集成（读取和写入）", "基于产品和交易知识的 RAG 索引", "电子邮件和日历工具", "护栏和陈述验证层", "外发操作的人工审批环节", "可观测性和语义缓存" ], "referenceScenario": { "context": "一家中型市场 B2B 软件供应商为其销售团队配备了 Copilot，以减轻行政负担并提高客户研究和外联的质量。这是一个说明性的、与供应商无关的蓝图，而不是对特定部署的描述。", "scenario": "销售代表要求 Copilot 准备会议简报、起草续约和开拓电子邮件、总结客户历史记录、记录通话并推荐下一步最佳行动。Copilot 将每个产出物基于 CRM 状态和产品知识库进行知识植入，并在发送前将所有面向客户的草稿路由给销售代表进行审批。", "technology": "编排循环通过函数调用访问 CRM，通过 RAG 检索产品和交易数据，并使用电子邮件和日历工具。护栏验证产品和定价陈述，人工审批环节把关外发操作，LangSmith 或 Langfuse 提供追踪，并对重复研究进行语义缓存。", "load": "假设有几百名销售代表，每人每天发出数十个请求，在季度末会出现爆发式增长。研究和起草请求占主导地位；外发发送相对较少，因为每一个都需要经过人工审核。", "results": "此处的所有数据均为用于规划系统规模和进行测量的参考目标，并非保证：团队应根据自己的数据来衡量自身的结果。合理的指标包括减少会前研究和 CRM 记录所花费的时间、加快外联初稿的周转速度以及改善数据卫生状况——每项指标都需要在部署前后对照基线进行验证。" }, "benefits": [ "销售代表在行政工作（研究、记录和起草）上花费的时间更少，而有更多时间进行直接对话。", "外联和简报基于公司真实的 CRM 和产品数据，提高了相关性和一致性。", "人工审批环节使销售代表对每条面向客户的信息负责，同时仍能加速其工作流程。", "可观测性和追踪使系统具备可审计性，因此团队可以检查读取、起草和发送了哪些内容。" ], "risks": [ "如果知识植入和陈述验证较弱，幻觉产生的产品功能或价格可能会泄露到客户沟通中。", "如果护栏或审批环节配置不当，CRM 写入权限会带来损坏销售管线数据的风险。", "如果允许 Copilot 在没有真实审核的情况下发送内容，过度自动化可能会削弱销售代表的判断力并损害客户关系。", "流经检索和提示词的敏感客户及交易数据会引发隐私和访问控制方面的担忧。" ], "failureModes": [ "由于检索遗漏了权威来源，智能体断言了过时或完全错误的功能或价格。", "销售代表不加阅读就直接批准草稿，使审批环节流于形式，从而导致错误内容被发送出去。", "陈旧或不完整的 CRM 读取导致智能体对已无法反映实际情况的交易阶段或联系人进行简报。", "编排循环对模糊的请求进行过度规划或陷入循环，在无法收敛的情况下消耗 Token 并增加延迟。" ], "lessons": [ "尽早将起草与发送分离；人工审批环节是外发工作中最重要的一项安全控制措施。", "将产品和定价陈述视为“必须引用”：如果无法附加来源，则不应发布该陈述。", "从第一天起就进行检测（instrument）——如果没有追踪，您将无法判断 Copilot 是提供了帮助，还是仅仅产生了更多的活动。", "严格且可逆地限制 CRM 写入范围，将高风险、客户可见的变更置于销售代表的明确确认之后。" ], "kpis": [ { "metric": "每位销售代表在研究和记录上节省的时间", "note": "衡量部署前后会前研究和 CRM 记录的时间；理想情况是时间明显且持续地减少，同时不损失数据质量。" }, { "metric": "审批环节的修改和拒绝率", "note": "追踪销售代表修改或拒绝草稿的频率；一个健康且不容忽视的比率表明销售代表是在进行真实的评审，而不是流于形式地直接批准。" }, { "metric": "知识植入和陈述验证的准确率", "note": "对草稿进行抽样，并对照权威来源检查产品和定价陈述；理想情况是几乎没有无法验证的陈述发送给客户。" }, { "metric": "对销售管线和转化率的影响", "note": "比较 Copilot 辅助活动与基线活动的转化率或推进情况；谨慎归因，并寻找真实、持久的提升。" }, { "metric": "每次辅助任务的成本和延迟", "note": "跟踪单次请求的 token 数量、检索调用次数和响应时间；随着使用量的增长，语义缓存应使成本和延迟保持稳定。" } ], "scaling": [ "成本主要由检索量和单次请求的模型调用次数驱动；对重复的客户研究和产品解答进行语义缓存是控制成本的主要手段。", "读密集型流量（研究、简报、总结）可水平扩展并受益于缓存；外发写入较少，且受限于人工审核。", "季度末和营销活动期间的突发流量需要检索和推理能力留有余量，并辅以速率限制，以防少数重度用户占用过多资源导致其他用户无法使用。", "随着产品目录和 CRM 的增长，检索新鲜度和索引维护在运营成本中占主导地位，其影响超过了纯推理成本。" ], "examples": [ "销售代表请求续签电话简报；Copilot 从 CRM 中读取客户信息，检索相关的合同和产品文档，并起草附带来源的谈话要点。", "在需求沟通电话会议后，销售代表口述记录；Copilot 向 CRM 记录结构化活动，并建议一封跟进邮件，由销售代表在发送前进行编辑和批准。", "Copilot 扫描销售代表的业务板块，并呈现“下一步最佳行动”——沉寂的客户、即将到期的合同、增售信号——每个行动都链接到其背后的 CRM 记录。" ], "faqs": [ { "q": "Copilot 可以自行向客户发送电子邮件吗？", "a": "不能。在设计上它仅起草内容；每一封面向客户的电子邮件、跟进或邀请都必须通过人工审批关卡，由销售代表在发送前进行审查、编辑和批准。" }, { "q": "如何防止它虚构产品功能或价格？", "a": "关于产品或定价的事实性陈述必须基于检索到的权威来源并附带引用。护栏机制会拒绝断言无法验证的具体细节的输出，并且会对草稿进行抽样以验证准确性。" }, { "q": "如何衡量它是否真正起到了帮助作用？", "a": "通过真实的指标——在研究和记录上节省的时间、审批关卡的编辑率、依据准确性（grounding accuracy）以及谨慎归因的销售管线（pipeline）影响——并与基线进行对比，而不是仅看原始活动计数。" } ] } } }, { "id": "ARCH-004", "slug": "ai-workforce", "category": "workforce", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/architectures/ai-workforce", "api": "https://santismm.com/api/architectures/ai-workforce", "canonical_url": "https://santismm.com/en/architectures/ai-workforce", "api_url": "https://santismm.com/api/architectures/ai-workforce", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "medium", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "Multi-agent orchestration (LangGraph)", "Agent registry", "Shared memory / state store", "Human oversight & approvals", "Guardrails", "Observability (LangSmith / Langfuse)" ], "patterns": [ "supervisor-agent", "orchestrator-workers", "goal-decomposition", "human-escalation", "task-prioritization" ], "knowledge": [ "multi-agent-architecture", "ai-agent", "agentic-evaluation", "ai-observability", "ai-governance" ], "references": [ { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" } ], "related": [ "customer-service-agent", "enterprise-knowledge-assistant", "operations-center", "sales-copilot" ], "locales": { "en": { "name": "AI Workforce", "summary": "An AI workforce is an orchestrated team of specialized agents that collaborate on multi-step business processes under a supervisor. The supervisor decomposes a goal, prioritizes and delegates subtasks to specialist agents (research, drafting, QA), and they share state through a common store. Agents escalate to humans when out of depth, and every step is observable and governed. Treat it as managing digital workers: success depends less on any single agent and more on coordination, clear ownership via an agent registry, human oversight, and evaluating the whole team rather than parts.", "keyConcepts": [ "A supervisor decomposes goals and delegates to specialist agents rather than one agent doing everything.", "Shared state and an agent registry give the team memory, clear ownership, and discoverable capabilities.", "Human oversight, escalation, and governance bound the blast radius when agents act incorrectly.", "You evaluate and measure the workforce as a system, not each agent in isolation." ], "definition": "The AI workforce architecture is a governed, multi-agent system in which a supervisor decomposes goals and delegates prioritized subtasks to specialized agents that share state, escalate to humans, and are observed end to end.", "architecture": [ "At the center sits a supervisor (or orchestrator) that receives a business goal, decomposes it into a plan of subtasks, prioritizes them, and routes each to the specialist agent best suited to it. Specialists — for example research, drafting, QA, and tooling agents — are registered in an agent registry that records each agent's capabilities, inputs, outputs, cost, and owner, so the supervisor can discover and select them and humans can hold someone accountable for behavior.", "Agents do not pass everything through prompts. They read and write a shared memory or state store that holds the evolving job context, intermediate artifacts, and decisions. This shared state is what turns a loose collection of agents into a team: it preserves continuity across steps, lets agents build on each other's work, and gives observability and audit a single source of truth. Guardrails sit between agents and tools or data to constrain actions, validate outputs, and prevent unsafe operations.", "Wrapping the whole system are human oversight and governance. Defined escalation paths let an agent hand off to a person when confidence is low or a task is high-stakes, and approval gates require human sign-off before irreversible actions. Observability (traces, evaluations, cost and latency per agent and per job) makes the team's behavior legible. Because failures in one agent can cascade, the architecture deliberately limits the blast radius through scoping, timeouts, and circuit-breakers." ], "flow": [ "1. Intake: a business goal or job enters the system and the supervisor records it with context, priority, and ownership.", "2. Decompose and prioritize: the supervisor breaks the goal into ordered subtasks and ranks them, considering dependencies and urgency.", "3. Delegate: each subtask is routed to a specialist agent selected from the agent registry by capability and cost.", "4. Execute with shared state: agents work against guardrailed tools, reading and writing the shared store so later agents build on earlier results.", "5. Escalate or approve: when confidence is low or stakes are high, an agent escalates to a human or waits at an approval gate.", "6. Assemble, verify, and close: a QA step checks the combined output, the supervisor finalizes the job, and traces and metrics are emitted for evaluation." ], "components": [ "Supervisor / orchestrator that plans and delegates", "Agent registry of specialists with owners and capabilities", "Specialist agents (research, drafting, QA, tooling)", "Shared memory / state store for job context", "Guardrails over tools, data, and outputs", "Human oversight: escalation paths and approval gates", "Observability and evaluation across the workforce" ], "referenceScenario": { "context": "A mid-size enterprise wants to automate the drafting of customer-facing policy responses that today require a research step, a drafting step, and a compliance review before a human signs off.", "scenario": "A goal enters the system; the supervisor decomposes it into research, draft, and QA subtasks, delegates each to a specialist agent, and routes anything compliance-sensitive to a human approval gate before release.", "technology": "LangGraph for multi-agent orchestration, an agent registry for capability discovery and ownership, a shared state store for job context, guardrails over retrieval and tools, and LangSmith or Langfuse for tracing and evaluation.", "load": "Illustrative volume of a few thousand jobs per week, with bursts during business hours and a long tail of complex jobs that require human escalation.", "results": "All figures here are reference targets to instrument and measure in your own environment, not guarantees: aim to track end-to-end job success, escalation rate, rework rate, and cost per completed job, and validate them against a human baseline before claiming productivity gains." }, "benefits": [ "Specialization lets each agent be simpler, better evaluated, and easier to own than one monolithic agent.", "A supervisor with prioritization handles multi-step, dependency-laden work that a single agent struggles to sequence.", "Shared state and a registry make the team auditable, with clear ownership and discoverable capabilities.", "Human oversight and governance let you adopt automation incrementally while bounding risk." ], "risks": [ "Coordination cost grows non-linearly; more agents and handoffs can add latency and error compounding.", "An error in one agent can cascade across the team, widening the failure blast radius.", "Without an agent registry and clear ownership, behavior becomes opaque and no one is accountable.", "Productivity claims can be illusory if measured per-task rather than against an honest end-to-end human baseline." ], "failureModes": [ "Cascading failure: a wrong intermediate result is trusted downstream and corrupts the final output.", "Coordination deadlock or loops: agents wait on each other or re-delegate the same subtask indefinitely.", "Lost or stale shared state: agents act on out-of-date context and produce inconsistent results.", "Escalation gaps: an agent proceeds on a high-stakes task instead of handing off to a human." ], "lessons": [ "Start with the smallest team that works and add specialists only when a single agent demonstrably cannot cope.", "Invest early in the agent registry, ownership, and shared-state contracts; they are what make the system governable.", "Evaluate the whole workforce end to end, not just individual agents, because coordination is where it breaks.", "Design escalation and blast-radius limits from day one rather than bolting on governance after an incident." ], "kpis": [ { "metric": "End-to-end job success rate", "note": "Share of jobs completed correctly without human correction; the headline measure of whether the team actually works." }, { "metric": "Escalation rate", "note": "Fraction of jobs handed to humans; too high means weak automation, too low may mean unsafe over-automation." }, { "metric": "Rework / correction rate", "note": "How often outputs are sent back or fixed; rising rework signals cascading errors or weak QA." }, { "metric": "Cost per completed job", "note": "Total model, tool, and human-review cost per finished job; the real unit economics behind productivity claims." }, { "metric": "Coordination overhead", "note": "Added latency and token cost from handoffs versus a single-agent baseline; watch it grow with team size." } ], "scaling": [ "Scale by adding specialist agents behind the registry, but treat each addition as new coordination surface to evaluate.", "Partition work so independent subtasks run in parallel while preserving shared-state consistency.", "Apply timeouts, retries with backoff, and circuit-breakers so a slow or failing agent cannot stall the whole job.", "Tier human oversight: lighter review for low-stakes jobs, mandatory approval gates for irreversible or sensitive ones." ], "examples": [ "A research-and-report workflow where a supervisor delegates gathering, synthesis, and fact-check QA to separate agents.", "A customer-response pipeline that drafts replies but routes compliance-sensitive cases to a human approval gate.", "An operations back-office team of agents that triage tickets, prepare actions, and escalate exceptions to staff." ], "faqs": [ { "q": "How is this different from a single AI agent?", "a": "A single agent does all reasoning and tool use itself. An AI workforce is many coordinated agents under a supervisor that decomposes goals, delegates to specialists, shares state, and governs the whole team; the hard problems are coordination, ownership, and blast radius rather than any one agent's capability." }, { "q": "Do more agents always make the system better?", "a": "No. Each added agent introduces handoffs, latency, and new ways to fail. Add specialists only when a simpler team demonstrably cannot do the work, and measure coordination overhead so the cost of orchestration does not exceed its benefit." }, { "q": "How do we measure real productivity gains?", "a": "Measure end to end against an honest human baseline: job success, escalation, rework, and cost per completed job. Per-task speedups can hide downstream corrections and review time, so only count gains that survive full end-to-end evaluation." } ] }, "es": { "name": "Fuerza laboral de IA", "summary": "Una fuerza laboral de IA es un equipo orquestado de agentes especializados que colaboran en procesos de negocio de varios pasos bajo un supervisor. El supervisor descompone un objetivo, prioriza y delega subtareas a agentes especialistas (investigación, redacción, control de calidad), y comparten estado mediante un almacén común. Los agentes escalan a personas cuando superan su alcance, y cada paso es observable y está gobernado. Trátelo como gestionar trabajadores digitales: el éxito depende menos de un solo agente y más de la coordinación, la propiedad clara mediante un registro de agentes, la supervisión humana y la evaluación del equipo completo en lugar de sus partes.", "keyConcepts": [ "Un supervisor descompone objetivos y delega en agentes especialistas en lugar de que un solo agente lo haga todo.", "El estado compartido y un registro de agentes dan al equipo memoria, propiedad clara y capacidades descubribles.", "La supervisión humana, la escalada y la gobernanza acotan el radio de impacto cuando los agentes actúan mal.", "Se evalúa y mide la fuerza laboral como sistema, no cada agente de forma aislada." ], "definition": "La arquitectura de fuerza laboral de IA es un sistema multiagente gobernado en el que un supervisor descompone objetivos y delega subtareas priorizadas a agentes especializados que comparten estado, escalan a personas y se observan de extremo a extremo.", "architecture": [ "En el centro hay un supervisor (u orquestador) que recibe un objetivo de negocio, lo descompone en un plan de subtareas, las prioriza y enruta cada una al agente especialista más adecuado. Los especialistas —por ejemplo agentes de investigación, redacción, control de calidad y herramientas— se inscriben en un registro de agentes que recoge las capacidades, entradas, salidas, coste y propietario de cada agente, de modo que el supervisor pueda descubrirlos y seleccionarlos y las personas puedan responsabilizar a alguien del comportamiento.", "Los agentes no pasan todo por los prompts. Leen y escriben en una memoria o almacén de estado compartido que contiene el contexto cambiante del trabajo, los artefactos intermedios y las decisiones. Este estado compartido es lo que convierte un conjunto suelto de agentes en un equipo: preserva la continuidad entre pasos, permite que los agentes construyan sobre el trabajo de otros y da a la observabilidad y a la auditoría una única fuente de verdad. Las barreras de protección se sitúan entre los agentes y las herramientas o datos para restringir acciones, validar salidas y evitar operaciones inseguras.", "Envolviendo todo el sistema están la supervisión humana y la gobernanza. Las rutas de escalada definidas permiten que un agente ceda el control a una persona cuando la confianza es baja o la tarea es de alto riesgo, y las puertas de aprobación exigen el visto bueno humano antes de acciones irreversibles. La observabilidad (trazas, evaluaciones, coste y latencia por agente y por trabajo) hace legible el comportamiento del equipo. Como los fallos en un agente pueden propagarse, la arquitectura limita deliberadamente el radio de impacto mediante acotación, tiempos de espera y cortacircuitos." ], "flow": [ "1. Ingreso: un objetivo o trabajo de negocio entra en el sistema y el supervisor lo registra con contexto, prioridad y propiedad.", "2. Descomponer y priorizar: el supervisor divide el objetivo en subtareas ordenadas y las jerarquiza, considerando dependencias y urgencia.", "3. Delegar: cada subtarea se enruta a un agente especialista seleccionado del registro de agentes por capacidad y coste.", "4. Ejecutar con estado compartido: los agentes trabajan con herramientas protegidas por barreras, leyendo y escribiendo el almacén compartido para que los agentes posteriores construyan sobre los resultados previos.", "5. Escalar o aprobar: cuando la confianza es baja o el riesgo es alto, un agente escala a una persona o espera en una puerta de aprobación.", "6. Ensamblar, verificar y cerrar: un paso de control de calidad revisa la salida combinada, el supervisor finaliza el trabajo y se emiten trazas y métricas para su evaluación." ], "components": [ "Supervisor / orquestador que planifica y delega", "Registro de agentes con especialistas, propietarios y capacidades", "Agentes especialistas (investigación, redacción, control de calidad, herramientas)", "Memoria / almacén de estado compartido para el contexto del trabajo", "Barreras de protección sobre herramientas, datos y salidas", "Supervisión humana: rutas de escalada y puertas de aprobación", "Observabilidad y evaluación en toda la fuerza laboral" ], "referenceScenario": { "context": "Una empresa mediana quiere automatizar la redacción de respuestas de política dirigidas a clientes que hoy requieren un paso de investigación, uno de redacción y una revisión de cumplimiento antes de que una persona dé el visto bueno.", "scenario": "Un objetivo entra en el sistema; el supervisor lo descompone en subtareas de investigación, redacción y control de calidad, delega cada una a un agente especialista y enruta lo sensible al cumplimiento a una puerta de aprobación humana antes de su publicación.", "technology": "LangGraph para la orquestación multiagente, un registro de agentes para el descubrimiento de capacidades y la propiedad, un almacén de estado compartido para el contexto del trabajo, barreras de protección sobre la recuperación y las herramientas, y LangSmith o Langfuse para el trazado y la evaluación.", "load": "Volumen ilustrativo de unos pocos miles de trabajos por semana, con picos en horario laboral y una cola larga de trabajos complejos que requieren escalada humana.", "results": "Todas las cifras aquí son objetivos de referencia que instrumentar y medir en su propio entorno, no garantías: procure seguir el éxito de los trabajos de extremo a extremo, la tasa de escalada, la tasa de retrabajo y el coste por trabajo completado, y valídelos frente a una línea base humana antes de afirmar ganancias de productividad." }, "benefits": [ "La especialización permite que cada agente sea más simple, mejor evaluado y más fácil de gobernar que un único agente monolítico.", "Un supervisor con priorización maneja trabajo de varios pasos y con dependencias que a un solo agente le cuesta secuenciar.", "El estado compartido y un registro hacen al equipo auditable, con propiedad clara y capacidades descubribles.", "La supervisión humana y la gobernanza permiten adoptar la automatización de forma incremental acotando el riesgo." ], "risks": [ "El coste de coordinación crece de forma no lineal; más agentes y traspasos pueden añadir latencia y composición de errores.", "Un error en un agente puede propagarse por el equipo, ampliando el radio de impacto del fallo.", "Sin un registro de agentes y propiedad clara, el comportamiento se vuelve opaco y nadie rinde cuentas.", "Las afirmaciones de productividad pueden ser ilusorias si se miden por tarea en lugar de frente a una línea base humana honesta de extremo a extremo." ], "failureModes": [ "Fallo en cascada: un resultado intermedio erróneo se da por bueno aguas abajo y corrompe la salida final.", "Bloqueo o bucles de coordinación: los agentes se esperan mutuamente o redelegan la misma subtarea indefinidamente.", "Estado compartido perdido o desactualizado: los agentes actúan sobre contexto caduco y producen resultados inconsistentes.", "Brechas de escalada: un agente continúa con una tarea de alto riesgo en lugar de cederla a una persona." ], "lessons": [ "Empiece con el equipo más pequeño que funcione y añada especialistas solo cuando un único agente demuestre no poder afrontarlo.", "Invierta pronto en el registro de agentes, la propiedad y los contratos de estado compartido; son lo que hace gobernable al sistema.", "Evalúe la fuerza laboral completa de extremo a extremo, no solo agentes individuales, porque la coordinación es donde se rompe.", "Diseñe la escalada y los límites de radio de impacto desde el primer día en lugar de añadir gobernanza tras un incidente." ], "kpis": [ { "metric": "Tasa de éxito de trabajos de extremo a extremo", "note": "Proporción de trabajos completados correctamente sin corrección humana; la medida principal de si el equipo realmente funciona." }, { "metric": "Tasa de escalada", "note": "Fracción de trabajos cedidos a personas; demasiado alta indica automatización débil, demasiado baja puede indicar sobreautomatización insegura." }, { "metric": "Tasa de retrabajo / corrección", "note": "Con qué frecuencia se devuelven o corrigen las salidas; un retrabajo creciente señala errores en cascada o un control de calidad débil." }, { "metric": "Coste por trabajo completado", "note": "Coste total de modelo, herramientas y revisión humana por trabajo terminado; la economía unitaria real tras las afirmaciones de productividad." }, { "metric": "Sobrecarga de coordinación", "note": "Latencia y coste de tokens añadidos por los traspasos frente a una línea base de un solo agente; vigile cómo crece con el tamaño del equipo." } ], "scaling": [ "Escale añadiendo agentes especialistas tras el registro, pero trate cada añadido como nueva superficie de coordinación que evaluar.", "Particione el trabajo para que las subtareas independientes se ejecuten en paralelo preservando la consistencia del estado compartido.", "Aplique tiempos de espera, reintentos con retroceso y cortacircuitos para que un agente lento o fallido no detenga todo el trabajo.", "Escalone la supervisión humana: revisión más ligera para trabajos de bajo riesgo, puertas de aprobación obligatorias para los irreversibles o sensibles." ], "examples": [ "Un flujo de investigación e informe donde un supervisor delega la recopilación, la síntesis y el control de calidad de verificación a agentes distintos.", "Una tubería de respuesta a clientes que redacta respuestas pero enruta los casos sensibles al cumplimiento a una puerta de aprobación humana.", "Un equipo de back-office de operaciones con agentes que clasifican tickets, preparan acciones y escalan excepciones al personal." ], "faqs": [ { "q": "¿En qué se diferencia esto de un único agente de IA?", "a": "Un único agente realiza por sí mismo todo el razonamiento y uso de herramientas. Una fuerza laboral de IA son muchos agentes coordinados bajo un supervisor que descompone objetivos, delega en especialistas, comparte estado y gobierna a todo el equipo; los problemas difíciles son la coordinación, la propiedad y el radio de impacto más que la capacidad de un solo agente." }, { "q": "¿Más agentes siempre mejoran el sistema?", "a": "No. Cada agente añadido introduce traspasos, latencia y nuevas formas de fallar. Añada especialistas solo cuando un equipo más simple demuestre no poder hacer el trabajo, y mida la sobrecarga de coordinación para que el coste de la orquestación no supere su beneficio." }, { "q": "¿Cómo medimos las ganancias reales de productividad?", "a": "Mida de extremo a extremo frente a una línea base humana honesta: éxito de trabajos, escalada, retrabajo y coste por trabajo completado. Las aceleraciones por tarea pueden ocultar correcciones posteriores y tiempo de revisión, así que cuente solo las ganancias que sobreviven a una evaluación completa de extremo a extremo." } ] }, "pt": { "name": "Força de trabalho de IA", "summary": "Uma força de trabalho de IA é uma equipe orquestrada de agentes especializados que colaboram em processos de negócio de várias etapas sob um supervisor. O supervisor decompõe um objetivo, prioriza e delega subtarefas a agentes especialistas (pesquisa, redação, controle de qualidade), e eles compartilham estado por meio de um repositório comum. Os agentes escalam para pessoas quando ultrapassam seu alcance, e cada etapa é observável e governada. Trate-a como gerenciar trabalhadores digitais: o sucesso depende menos de um único agente e mais da coordenação, da propriedade clara via um registro de agentes, da supervisão humana e da avaliação da equipe inteira em vez de suas partes.", "keyConcepts": [ "Um supervisor decompõe objetivos e delega a agentes especialistas em vez de um único agente fazer tudo.", "O estado compartilhado e um registro de agentes dão à equipe memória, propriedade clara e capacidades descobríveis.", "A supervisão humana, a escalada e a governança limitam o raio de impacto quando os agentes agem de forma incorreta.", "Avalia-se e mede-se a força de trabalho como sistema, não cada agente isoladamente." ], "definition": "A arquitetura de força de trabalho de IA é um sistema multiagente governado no qual um supervisor decompõe objetivos e delega subtarefas priorizadas a agentes especializados que compartilham estado, escalam para pessoas e são observados de ponta a ponta.", "architecture": [ "No centro há um supervisor (ou orquestrador) que recebe um objetivo de negócio, o decompõe em um plano de subtarefas, as prioriza e roteia cada uma para o agente especialista mais adequado. Os especialistas — por exemplo agentes de pesquisa, redação, controle de qualidade e ferramentas — são inscritos em um registro de agentes que registra as capacidades, entradas, saídas, custo e responsável de cada agente, de modo que o supervisor possa descobri-los e selecioná-los e as pessoas possam responsabilizar alguém pelo comportamento.", "Os agentes não passam tudo pelos prompts. Eles leem e escrevem em uma memória ou repositório de estado compartilhado que contém o contexto em evolução do trabalho, os artefatos intermediários e as decisões. Esse estado compartilhado é o que transforma um conjunto solto de agentes em uma equipe: preserva a continuidade entre etapas, permite que os agentes construam sobre o trabalho uns dos outros e dá à observabilidade e à auditoria uma única fonte de verdade. As barreiras de proteção ficam entre os agentes e as ferramentas ou dados para restringir ações, validar saídas e evitar operações inseguras.", "Envolvendo todo o sistema estão a supervisão humana e a governança. Caminhos de escalada definidos permitem que um agente passe o controle a uma pessoa quando a confiança é baixa ou a tarefa é de alto risco, e portões de aprovação exigem o aval humano antes de ações irreversíveis. A observabilidade (rastreamentos, avaliações, custo e latência por agente e por trabalho) torna legível o comportamento da equipe. Como falhas em um agente podem se propagar, a arquitetura limita deliberadamente o raio de impacto por meio de escopo, tempos limite e disjuntores." ], "flow": [ "1. Entrada: um objetivo ou trabalho de negócio entra no sistema e o supervisor o registra com contexto, prioridade e propriedade.", "2. Decompor e priorizar: o supervisor divide o objetivo em subtarefas ordenadas e as hierarquiza, considerando dependências e urgência.", "3. Delegar: cada subtarefa é roteada para um agente especialista selecionado do registro de agentes por capacidade e custo.", "4. Executar com estado compartilhado: os agentes trabalham com ferramentas protegidas por barreiras, lendo e escrevendo o repositório compartilhado para que agentes posteriores construam sobre resultados anteriores.", "5. Escalar ou aprovar: quando a confiança é baixa ou o risco é alto, um agente escala para uma pessoa ou aguarda em um portão de aprovação.", "6. Montar, verificar e encerrar: uma etapa de controle de qualidade revisa a saída combinada, o supervisor finaliza o trabalho e rastreamentos e métricas são emitidos para avaliação." ], "components": [ "Supervisor / orquestrador que planeja e delega", "Registro de agentes com especialistas, responsáveis e capacidades", "Agentes especialistas (pesquisa, redação, controle de qualidade, ferramentas)", "Memória / repositório de estado compartilhado para o contexto do trabalho", "Barreiras de proteção sobre ferramentas, dados e saídas", "Supervisão humana: caminhos de escalada e portões de aprovação", "Observabilidade e avaliação em toda a força de trabalho" ], "referenceScenario": { "context": "Uma empresa de médio porte quer automatizar a redação de respostas de política voltadas ao cliente que hoje exigem uma etapa de pesquisa, uma de redação e uma revisão de conformidade antes que uma pessoa dê o aval.", "scenario": "Um objetivo entra no sistema; o supervisor o decompõe em subtarefas de pesquisa, redação e controle de qualidade, delega cada uma a um agente especialista e roteia o que é sensível à conformidade para um portão de aprovação humana antes da publicação.", "technology": "LangGraph para a orquestração multiagente, um registro de agentes para a descoberta de capacidades e a propriedade, um repositório de estado compartilhado para o contexto do trabalho, barreiras de proteção sobre a recuperação e as ferramentas, e LangSmith ou Langfuse para o rastreamento e a avaliação.", "load": "Volume ilustrativo de alguns milhares de trabalhos por semana, com picos no horário comercial e uma cauda longa de trabalhos complexos que exigem escalada humana.", "results": "Todos os números aqui são metas de referência a instrumentar e medir no seu próprio ambiente, não garantias: procure acompanhar o sucesso dos trabalhos de ponta a ponta, a taxa de escalada, a taxa de retrabalho e o custo por trabalho concluído, e valide-os contra uma linha de base humana antes de afirmar ganhos de produtividade." }, "benefits": [ "A especialização permite que cada agente seja mais simples, melhor avaliado e mais fácil de governar do que um único agente monolítico.", "Um supervisor com priorização lida com trabalho de várias etapas e cheio de dependências que um único agente tem dificuldade de sequenciar.", "O estado compartilhado e um registro tornam a equipe auditável, com propriedade clara e capacidades descobríveis.", "A supervisão humana e a governança permitem adotar a automação de forma incremental, limitando o risco." ], "risks": [ "O custo de coordenação cresce de forma não linear; mais agentes e repasses podem acrescentar latência e composição de erros.", "Um erro em um agente pode se propagar pela equipe, ampliando o raio de impacto da falha.", "Sem um registro de agentes e propriedade clara, o comportamento torna-se opaco e ninguém presta contas.", "Afirmações de produtividade podem ser ilusórias se medidas por tarefa em vez de contra uma linha de base humana honesta de ponta a ponta." ], "failureModes": [ "Falha em cascata: um resultado intermediário errado é tido como bom a jusante e corrompe a saída final.", "Impasse ou laços de coordenação: os agentes esperam uns pelos outros ou redelegam a mesma subtarefa indefinidamente.", "Estado compartilhado perdido ou desatualizado: os agentes agem sobre contexto vencido e produzem resultados inconsistentes.", "Lacunas de escalada: um agente prossegue numa tarefa de alto risco em vez de passá-la a uma pessoa." ], "lessons": [ "Comece com a menor equipe que funcione e adicione especialistas apenas quando um único agente comprovadamente não der conta.", "Invista cedo no registro de agentes, na propriedade e nos contratos de estado compartilhado; são eles que tornam o sistema governável.", "Avalie a força de trabalho inteira de ponta a ponta, não apenas agentes individuais, porque a coordenação é onde ela quebra.", "Projete a escalada e os limites de raio de impacto desde o primeiro dia em vez de acrescentar governança após um incidente." ], "kpis": [ { "metric": "Taxa de sucesso de trabalhos de ponta a ponta", "note": "Proporção de trabalhos concluídos corretamente sem correção humana; a medida principal de se a equipe de fato funciona." }, { "metric": "Taxa de escalada", "note": "Fração de trabalhos passados a pessoas; alta demais indica automação fraca, baixa demais pode indicar superautomação insegura." }, { "metric": "Taxa de retrabalho / correção", "note": "Com que frequência as saídas são devolvidas ou corrigidas; retrabalho crescente sinaliza erros em cascata ou controle de qualidade fraco." }, { "metric": "Custo por trabalho concluído", "note": "Custo total de modelo, ferramentas e revisão humana por trabalho finalizado; a economia unitária real por trás das afirmações de produtividade." }, { "metric": "Sobrecarga de coordenação", "note": "Latência e custo de tokens acrescentados pelos repasses ante uma linha de base de um único agente; observe como cresce com o tamanho da equipe." } ], "scaling": [ "Escale adicionando agentes especialistas atrás do registro, mas trate cada acréscimo como nova superfície de coordenação a avaliar.", "Particione o trabalho para que subtarefas independentes rodem em paralelo preservando a consistência do estado compartilhado.", "Aplique tempos limite, novas tentativas com recuo e disjuntores para que um agente lento ou com falha não trave o trabalho inteiro.", "Escalone a supervisão humana: revisão mais leve para trabalhos de baixo risco, portões de aprovação obrigatórios para os irreversíveis ou sensíveis." ], "examples": [ "Um fluxo de pesquisa e relatório onde um supervisor delega a coleta, a síntese e o controle de qualidade de verificação a agentes distintos.", "Um pipeline de resposta a clientes que redige respostas mas roteia os casos sensíveis à conformidade para um portão de aprovação humana.", "Uma equipe de back-office de operações com agentes que triam tickets, preparam ações e escalam exceções à equipe." ], "faqs": [ { "q": "Como isso difere de um único agente de IA?", "a": "Um único agente faz por si todo o raciocínio e uso de ferramentas. Uma força de trabalho de IA são muitos agentes coordenados sob um supervisor que decompõe objetivos, delega a especialistas, compartilha estado e governa a equipe inteira; os problemas difíceis são a coordenação, a propriedade e o raio de impacto, mais do que a capacidade de um único agente." }, { "q": "Mais agentes sempre tornam o sistema melhor?", "a": "Não. Cada agente acrescentado introduz repasses, latência e novas formas de falhar. Adicione especialistas apenas quando uma equipe mais simples comprovadamente não conseguir fazer o trabalho, e meça a sobrecarga de coordenação para que o custo da orquestração não exceda seu benefício." }, { "q": "Como medimos ganhos reais de produtividade?", "a": "Meça de ponta a ponta contra uma linha de base humana honesta: sucesso dos trabalhos, escalada, retrabalho e custo por trabalho concluído. Acelerações por tarefa podem esconder correções posteriores e tempo de revisão, então conte apenas os ganhos que sobrevivem a uma avaliação completa de ponta a ponta." } ] }, "fr": { "name": "Main-d'œuvre IA", "summary": "Une main-d'œuvre IA est une équipe orchestrée d'agents spécialisés qui collaborent sur des processus métier multi-étapes sous la direction d'un superviseur. Le superviseur décompose un objectif, hiérarchise et délègue les sous-tâches à des agents spécialisés (recherche, rédaction, assurance qualité), et ces derniers partagent leur état via un magasin commun. Les agents font remonter les cas aux humains lorsqu'ils dépassent leurs compétences, et chaque étape est observable et gouvernée. Considérez cela comme la gestion de travailleurs numériques : le succès dépend moins d'un agent individuel que de la coordination, d'une responsabilité claire via un registre d'agents, d'une supervision humaine et de l'évaluation de l'ensemble de l'équipe plutôt que de ses composants.", "keyConcepts": [ "Un superviseur décompose les objectifs et délègue aux agents spécialisés plutôt qu'un seul agent ne fasse tout.", "L'état partagé et un registre d'agents dotent l'équipe d'une mémoire, d'une responsabilité claire et de capacités découvrables.", "La supervision humaine, l'escalade et la gouvernance limitent le rayon d'impact en cas de comportement incorrect des agents.", "Vous évaluez et mesurez la main-d'œuvre comme un système global, et non chaque agent de manière isolée." ], "definition": "L'architecture de main-d'œuvre IA est un système multi-agent gouverné dans lequel un superviseur décompose les objectifs et délègue des sous-tâches hiérarchisées à des agents spécialisés qui partagent leur état, font remonter les cas aux humains et sont observés de bout en bout.", "architecture": [ "Au centre se trouve un superviseur (ou orchestrateur) qui reçoit un objectif métier, le décompose en un plan de sous-tâches, les hiérarchise et oriente chacune vers l'agent spécialisé le plus adapté. Les spécialistes — par exemple, les agents de recherche, de rédaction, d'assurance qualité et d'outillage — sont répertoriés dans un registre d'agents qui enregistre les capacités, les entrées, les sorties, le coût et le propriétaire de chaque agent, afin que le superviseur puisse les découvrir et les sélectionner, et que les humains puissent attribuer la responsabilité des comportements.", "Les agents ne transmettent pas tout via des prompts. Ils lisent et écrivent dans une mémoire partagée ou un magasin d'états qui conserve le contexte évolutif de la tâche, les artefacts intermédiaires et les décisions. Cet état partagé est ce qui transforme une simple collection d'agents en une véritable équipe : il préserve la continuité entre les étapes, permet aux agents de s'appuyer sur le travail des autres et offre une source unique de vérité pour l'observabilité et l'audit. Des garde-fous sont placés entre les agents et les outils ou les données afin de contraindre les actions, de valider les sorties et d'empêcher les opérations non sécurisées.", "La supervision humaine et la gouvernance encadrent l'ensemble du système. Des parcours d'escalade définis permettent à un agent de passer le relais à une personne lorsque le niveau de confiance est faible ou que les enjeux d'une tâche sont élevés, et des jalons d'approbation exigent une validation humaine avant toute action irréversible. L'observabilité (traces, évaluations, coût et latence par agent et par tâche) rend le comportement de l'équipe lisible. Étant donné que les défaillances d'un agent peuvent se propager en cascade, l'architecture limite délibérément le rayon d'impact grâce au ciblage du périmètre, aux délais d'expiration et aux disjoncteurs." ], "flow": [ "1. Réception : un objectif métier ou une tâche entre dans le système et le superviseur l'enregistre avec son contexte, sa priorité et sa responsabilité.", "2. Décomposition et hiérarchisation : le superviseur décompose l'objectif en sous-tâches ordonnées et les classe en tenant compte des dépendances et de l'urgence.", "3. Délégation : chaque sous-tâche est orientée vers un agent spécialisé sélectionné dans le registre d'agents en fonction de ses capacités et de son coût.", "4. Exécution avec état partagé : les agents travaillent avec des outils encadrés par des garde-fous, lisant et écrivant dans le magasin partagé afin que les agents suivants s'appuient sur les résultats précédents.", "5. Escalade ou approbation : lorsque le niveau de confiance est faible ou que les enjeux sont élevés, un agent fait remonter le cas à un humain ou attend à un jalon d'approbation.", "6. Assemblage, vérification et clôture : une étape d'assurance qualité vérifie le résultat combiné, le superviseur finalise la tâche, et des traces ainsi que des métriques sont émises pour évaluation." ], "components": [ "Superviseur / orchestrateur qui planifie et délègue", "Registre d'agents spécialistes avec propriétaires et capacités", "Agents spécialisés (recherche, rédaction, assurance qualité, outillage)", "Mémoire partagée / magasin d'états pour le contexte de la tâche", "Garde-fous sur les outils, les données et les sorties", "Supervision humaine : parcours d'escalade et jalons d'approbation", "Observabilité et évaluation de l'ensemble de la main-d'œuvre" ], "referenceScenario": { "context": "Une entreprise de taille moyenne souhaite automatiser la rédaction de réponses aux politiques destinées aux clients, qui nécessitent aujourd'hui une étape de recherche, une étape de rédaction et un examen de conformité avant validation par un humain.", "scenario": "Un objectif entre dans le système ; le superviseur le décompose en sous-tâches de recherche, de rédaction et d'assurance qualité, délègue chacune à un agent spécialisé et oriente tout élément sensible en matière de conformité vers un jalon d'approbation humaine avant publication.", "technology": "LangGraph pour l'orchestration multi-agent, un registre d'agents pour la découverte des capacités et la responsabilité, un magasin d'états partagé pour le contexte de la tâche, des garde-fous sur la récupération et les outils, et LangSmith ou Langfuse pour le traçage et l'évaluation.", "load": "Volume illustratif de quelques milliers de tâches par semaine, avec des pics pendant les heures de bureau et une longue traîne de tâches complexes nécessitant une escalade humaine.", "results": "Tous les chiffres présentés ici sont des cibles de référence à instrumenter et à mesurer dans votre propre environnement, et non des garanties : cherchez à suivre le taux de réussite des tâches de bout en bout, le taux d'escalade, le taux de retravail et le coût par tâche finalisée, puis validez-les par rapport à une référence humaine avant de revendiquer des gains de productivité." }, "benefits": [ "La spécialisation permet à chaque agent d'être plus simple, mieux évalué et plus facile à attribuer qu'un agent monolithique unique.", "Un superviseur doté d'une fonction de hiérarchisation gère les travaux multi-étapes comportant de nombreuses dépendances, qu'un agent unique peinerait à ordonnancer.", "L'état partagé et un registre rendent l'équipe auditable, avec une responsabilité claire et des capacités découvrables.", "La supervision humaine et la gouvernance vous permettent d'adopter l'automatisation de manière progressive tout en limitant les risques." ], "risks": [ "Le coût de coordination augmente de manière non linéaire ; multiplier les agents et les transferts peut accroître la latence et cumuler les erreurs.", "Une erreur chez un agent peut se propager en cascade à toute l'équipe, élargissant ainsi le rayon d'impact de la défaillance.", "Sans registre d'agents ni responsabilité claire, le comportement devient opaque et personne n'est tenu pour responsable.", "Les gains de productivité revendiqués peuvent être illusoires s'ils sont mesurés par tâche plutôt que par rapport à une référence humaine de bout en bout honnête." ], "failureModes": [ "Défaillance en cascade : un résultat intermédiaire erroné est considéré comme fiable en aval et corrompt la sortie finale.", "Impasse ou boucles de coordination : les agents s'attendent mutuellement ou redélèguent indéfiniment la même sous-tâche.", "État partagé perdu ou obsolète : les agents agissent sur la base d'un contexte obsolète et produisent des résultats incohérents.", "Défauts d'escalade : un agent poursuit une tâche à enjeux élevés au lieu de passer le relais à un humain." ], "lessons": [ "Commencez par la plus petite équipe fonctionnelle et n'ajoutez des spécialistes que lorsqu'il est prouvé qu'un agent unique ne peut pas faire face.", "Investissez tôt dans le registre d'agents, la responsabilité et les contrats d'état partagé ; ce sont eux qui rendent le système gouvernable.", "Évaluez l'ensemble de la main-d'œuvre de bout en bout, et pas seulement les agents individuels, car c'est au niveau de la coordination que le système fléchit.", "Concevez l'escalade et les limites du rayon d'impact dès le premier jour, plutôt que de greffer une gouvernance après un incident." ], "kpis": [ { "metric": "Taux de réussite des tâches de bout en bout", "note": "Part des tâches correctement accomplies sans correction humaine ; la mesure principale pour savoir si l'équipe fonctionne réellement." }, { "metric": "Taux d'escalade", "note": "Fraction des tâches confiées à des humains ; un taux trop élevé indique une automatisation faible, un taux trop bas peut signifier une sur-automatisation risquée." }, { "metric": "Taux de retravail / correction", "note": "Fréquence à laquelle les sorties sont renvoyées ou corrigées ; une hausse du retravail signale des erreurs en cascade ou une assurance qualité insuffisante." }, { "metric": "Coût par tâche finalisée", "note": "Coût total des modèles, des outils et de la révision humaine par tâche terminée ; l'économie unitaire réelle derrière les revendications de productivité." }, { "metric": "Surcharge de coordination", "note": "Latence et coût en jetons supplémentaires générés par les transferts par rapport à une référence d'agent unique ; observez sa croissance avec la taille de l'équipe." } ], "scaling": [ "Passez à l'échelle en ajoutant des agents spécialisés derrière le registre, mais traitez chaque ajout comme une nouvelle surface de coordination à évaluer.", "Partitionnez le travail afin que les sous-tâches indépendantes s'exécutent en parallèle tout en préservant la cohérence de l'état partagé.", "Appliquez des délais d'expiration, des tentatives avec retrait (backoff) et des disjoncteurs pour qu'un agent lent ou défaillant ne bloque pas l'ensemble de la tâche.", "Échelonnez la supervision humaine : examen plus léger pour les tâches à faibles enjeux, jalons d'approbation obligatoires pour celles qui sont irréversibles ou sensibles." ], "examples": [ "Un flux de travail de recherche et de rapport dans lequel un superviseur délègue la collecte, la synthèse et l'assurance qualité de vérification des faits à des agents distincts.", "Un pipeline de réponse client qui rédige des réponses mais oriente les cas sensibles en matière de conformité vers un jalon d'approbation humaine.", "Une équipe d'agents de back-office opérationnel qui trie les tickets, prépare les actions et fait remonter les exceptions au personnel." ], "faqs": [ { "q": "En quoi cela diffère-t-il d'un agent IA unique ?", "a": "Un agent unique gère lui-même l'ensemble du raisonnement et de l'utilisation des outils. Une main-d'œuvre IA est constituée de nombreux agents coordonnés sous la direction d'un superviseur qui décompose les objectifs, délègue aux spécialistes, partage l'état et gouverne toute l'équipe ; les problèmes complexes résident dans la coordination, la responsabilité et le rayon d'impact, plutôt que dans la capacité d'un agent individuel." }, { "q": "Est-ce qu'un plus grand nombre d'agents rend toujours le système plus performant ?", "a": "Non. Chaque agent supplémentaire introduit des transferts, de la latence et de nouveaux risques de défaillance. N'ajoutez des spécialistes que lorsqu'il est prouvé qu'une équipe plus simple ne peut pas effectuer le travail, et mesurez la surcharge de coordination afin que le coût de l'orchestration ne dépasse pas ses bénéfices." }, { "q": "Comment mesurer les gains de productivité réels ?", "a": "Mesurez de bout en bout par rapport à une référence humaine objective : taux de réussite des tâches, escalades, retouches et coût par tâche accomplie. Les gains de vitesse par tâche peuvent masquer les corrections en aval et le temps de révision ; ne comptabilisez donc que les gains qui subsistent après une évaluation complète de bout en bout." } ] }, "de": { "name": "AI Workforce", "summary": "Eine AI Workforce ist ein orchestriertes Team spezialisierter Agenten, die unter der Leitung eines Supervisors bei mehrstufigen Geschäftsprozessen zusammenarbeiten. Der Supervisor zerlegt ein Ziel, priorisiert und delegiert Teilaufgaben an spezialisierte Agenten (Recherche, Entwurf, QS), und diese teilen ihren Zustand über einen gemeinsamen Speicher. Agenten eskalieren an Menschen, wenn sie an ihre Grenzen stoßen, und jeder Schritt ist beobachtbar und gesteuert. Betrachten Sie dies wie das Management digitaler Mitarbeiter: Der Erfolg hängt weniger von einem einzelnen Agenten ab, sondern vielmehr von der Koordination, einer klaren Verantwortlichkeit über ein Agenten-Registry, menschlicher Aufsicht und der Bewertung des gesamten Teams anstelle einzelner Teile.", "keyConcepts": [ "Ein Supervisor zerlegt Ziele und delegiert sie an spezialisierte Agenten, anstatt dass ein einzelner Agent alles erledigt.", "Ein gemeinsamer Zustand (Shared State) und ein Agenten-Registry verleihen dem Team ein Gedächtnis, klare Verantwortlichkeiten und auffindbare Fähigkeiten.", "Menschliche Aufsicht, Eskalation und Governance begrenzen den Schadensradius (Blast Radius), wenn Agenten fehlerhaft agieren.", "Sie bewerten und messen die Workforce als System und nicht jeden Agenten isoliert." ], "definition": "Die AI-Workforce-Architektur ist ein gesteuertes Multi-Agenten-System, in dem ein Supervisor Ziele zerlegt und priorisierte Teilaufgaben an spezialisierte Agenten delegiert, die einen gemeinsamen Zustand teilen, an Menschen eskalieren und durchgängig (End-to-End) überwacht werden.", "architecture": [ "Im Zentrum steht ein Supervisor (oder Orchestrator), der ein Geschäftsziel empfängt, es in einen Plan aus Teilaufgaben zerlegt, diese priorisiert und jede an den am besten geeigneten spezialisierten Agenten weiterleitet. Spezialisten – beispielsweise Agenten für Recherche, Entwurf, QS und Tool-Nutzung – sind in einem Agenten-Registry registriert. Dieses erfasst die Fähigkeiten, Eingaben, Ausgaben, Kosten und Verantwortlichen jedes Agenten, sodass der Supervisor sie finden und auswählen kann und Menschen die Verantwortung für deren Verhalten zuweisen können.", "Agenten übergeben nicht alles über Prompts. Sie lesen und schreiben in einen gemeinsamen Speicher oder Zustandsspeicher (State Store), der den sich entwickelnden Aufgabenkontext, Zwischenergebnisse und Entscheidungen enthält. Dieser gemeinsame Zustand macht aus einer losen Sammlung von Agenten erst ein Team: Er wahrt die Kontinuität über Schritte hinweg, lässt Agenten auf der Arbeit der anderen aufbauen und bietet eine Single Source of Truth für Observability und Audits. Guardrails befinden sich zwischen Agenten und Tools oder Daten, um Aktionen einzuschränken, Ausgaben zu validieren und unsichere Operationen zu verhindern.", "Das gesamte System wird von menschlicher Aufsicht und Governance umrahmt. Definierte Eskalationspfade ermöglichen es einem Agenten, an eine Person zu übergeben, wenn das Vertrauen (Confidence) gering ist oder eine Aufgabe ein hohes Risiko birgt. Approval Gates erfordern eine menschliche Freigabe vor irreversiblen Aktionen. Observability (Traces, Evaluierungen, Kosten und Latenz pro Agent und Job) macht das Verhalten des Teams nachvollziehbar. Da Fehler bei einem Agenten kaskadieren können, begrenzt die Architektur den Schadensradius (Blast Radius) bewusst durch Scoping, Timeouts und Circuit-Breaker." ], "flow": [ "1. Erfassung (Intake): Ein Geschäftsziel oder ein Job geht im System ein, und der Supervisor erfasst diesen mit Kontext, Priorität und Verantwortlichkeit.", "2. Zerlegung und Priorisierung: Der Supervisor zerlegt das Ziel in geordnete Teilaufgaben und stuft diese unter Berücksichtigung von Abhängigkeiten und Dringlichkeit ein.", "3. Delegation: Jede Teilaufgabe wird an einen spezialisierten Agenten weitergeleitet, der basierend auf Fähigkeiten und Kosten aus dem Agenten-Registry ausgewählt wird.", "4. Ausführung mit gemeinsamem Zustand: Agenten arbeiten mit durch Guardrails geschützten Tools und lesen bzw. schreiben in den gemeinsamen Speicher, sodass nachfolgende Agenten auf früheren Ergebnissen aufbauen.", "5. Eskalation oder Freigabe: Wenn das Vertrauen gering ist oder viel auf dem Spiel steht, eskaliert ein Agent an einen Menschen oder wartet an einem Approval Gate.", "6. Zusammenführung, Verifizierung und Abschluss: Ein QS-Schritt prüft die kombinierte Ausgabe, der Supervisor schließt den Job ab, und Traces sowie Metriken werden zur Evaluierung ausgegeben." ], "components": [ "Supervisor / Orchestrator, der plant und delegiert", "Agenten-Registry von Spezialisten mit Verantwortlichen und Fähigkeiten", "Spezialisierte Agenten (Recherche, Entwurf, QS, Tool-Nutzung)", "Gemeinsamer Speicher / Zustandsspeicher (State Store) für den Aufgabenkontext", "Guardrails für Tools, Daten und Ausgaben", "Menschliche Aufsicht: Eskalationspfade und Approval Gates", "Observability und Evaluierung über die gesamte Workforce hinweg" ], "referenceScenario": { "context": "Ein mittelständisches Unternehmen möchte die Erstellung von kundenorientierten Richtlinien-Antworten automatisieren, die heute einen Recherche-Schritt, einen Entwurfs-Schritt und eine Compliance-Prüfung erfordern, bevor ein Mensch sie freigibt.", "scenario": "Ein Ziel geht im System ein; der Supervisor zerlegt es in Teilaufgaben für Recherche, Entwurf und QS, delegiert diese jeweils an einen spezialisierten Agenten und leitet alle compliance-relevanten Aspekte vor der Veröffentlichung an ein menschliches Approval Gate weiter.", "technology": "LangGraph für die Multi-Agenten-Orchestrierung, ein Agenten-Registry zur Erkennung von Fähigkeiten und Verantwortlichkeiten, ein gemeinsamer Zustandsspeicher für den Aufgabenkontext, Guardrails für Retrieval und Tools sowie LangSmith oder Langfuse für Tracing und Evaluierung.", "load": "Beispielhaftes Volumen von einigen tausend Jobs pro Woche, mit Spitzenwerten während der Geschäftszeiten und einem Long-Tail komplexer Jobs, die eine menschliche Eskalation erfordern.", "results": "Alle hier genannten Zahlen sind Richtwerte zur Instrumentierung und Messung in Ihrer eigenen Umgebung, keine Garantien: Versuchen Sie, den End-to-End-Erfolg von Jobs, die Eskalationsrate, die Nacharbeitsquote und die Kosten pro abgeschlossenem Job zu erfassen und diese mit einer menschlichen Baseline abzugleichen, bevor Sie Produktivitätssteigerungen geltend machen." }, "benefits": [ "Spezialisierung sorgt dafür, dass jeder Agent einfacher aufgebaut, besser zu evaluieren und leichter zu verwalten ist als ein einzelner monolithischer Agent.", "Ein Supervisor mit Priorisierungsfunktion bewältigt mehrstufige, von Abhängigkeiten geprägte Aufgaben, bei denen ein einzelner Agent Schwierigkeiten mit der Sequenzierung hätte.", "Ein gemeinsamer Zustand und ein Registry machen das Team auditierbar, mit klaren Verantwortlichkeiten und auffindbaren Fähigkeiten.", "Menschliche Aufsicht und Governance ermöglichen es Ihnen, Automatisierung schrittweise einzuführen und gleichzeitig Risiken zu begrenzen." ], "risks": [ "Die Koordinationskosten steigen nicht-linear; mehr Agenten und Übergaben können zu zusätzlicher Latenz und einer Fehlerkumulation führen.", "Ein Fehler in einem Agenten kann sich über das gesamte Team kaskadenartig ausbreiten und den Schadensradius des Ausfalls vergrößern.", "Ohne ein Agenten-Registry und klare Verantwortlichkeiten wird das Verhalten intransparent und niemand übernimmt die Verantwortung.", "Produktivitätsversprechen können illusorisch sein, wenn sie pro Aufgabe gemessen werden und nicht im Vergleich zu einer ehrlichen, durchgängigen menschlichen Baseline." ], "failureModes": [ "Kaskadierender Fehler: Ein falsches Zwischenergebnis wird im weiteren Verlauf als vertrauenswürdig eingestuft und verfälscht die endgültige Ausgabe.", "Koordinations-Deadlock oder Endlosschleifen: Agenten warten aufeinander oder delegieren dieselbe Teilaufgabe unendlich oft neu.", "Verlorener oder veralteter gemeinsamer Zustand: Agenten agieren auf Basis eines veralteten Kontexts und erzeugen inkonsistente Ergebnisse.", "Eskalationslücken: Ein Agent fährt mit einer risikoreichen Aufgabe fort, anstatt sie an einen Menschen zu übergeben." ], "lessons": [ "Beginnen Sie mit dem kleinstmöglichen funktionierenden Team und fügen Sie Spezialisten erst dann hinzu, wenn ein einzelner Agent nachweislich überfordert ist.", "Investieren Sie frühzeitig in das Agenten-Registry, Verantwortlichkeiten und Verträge für den gemeinsamen Zustand (Shared-State Contracts); sie machen das System erst steuerbar.", "Evaluieren Sie die gesamte Workforce durchgängig (End-to-End) und nicht nur einzelne Agenten, da Fehler meist bei der Koordination auftreten.", "Konzipieren Sie Eskalationspfade und Grenzen für den Schadensradius vom ersten Tag an, anstatt Governance erst nach einem Vorfall hinzuzufügen." ], "kpis": [ { "metric": "End-to-End-Erfolgsquote von Jobs", "note": "Anteil der korrekt abgeschlossenen Jobs ohne menschliche Korrektur; die wichtigste Kennzahl dafür, ob das Team tatsächlich funktioniert." }, { "metric": "Eskalationsrate", "note": "Anteil der an Menschen übergebenen Jobs; ein zu hoher Wert deutet auf eine schwache Automatisierung hin, ein zu niedriger Wert kann eine unsichere Überautomatisierung bedeuten." }, { "metric": "Nacharbeits- / Korrekturquote", "note": "Wie oft Ausgaben zurückgesendet oder korrigiert werden; eine steigende Nacharbeitsquote signalisiert kaskadierende Fehler oder eine schwache QS." }, { "metric": "Kosten pro abgeschlossenem Job", "note": "Gesamtkosten für Modell, Tools und menschliche Überprüfung pro fertiggestelltem Job; die tatsächliche Unit Economics hinter Produktivitätsversprechen." }, { "metric": "Koordinations-Overhead", "note": "Zusätzliche Latenz und Token-Kosten durch Übergaben im Vergleich zu einer Einzel-Agenten-Baseline; beobachten Sie, wie dieser Wert mit der Teamgröße wächst." } ], "scaling": [ "Skalieren Sie, indem Sie spezialisierte Agenten hinter dem Registry hinzufügen, aber betrachten Sie jede Hinzufügung als neue zu evaluierende Koordinationsfläche.", "Teilen Sie die Arbeit so auf, dass unabhängige Teilaufgaben parallel ausgeführt werden, während die Konsistenz des gemeinsamen Zustands gewahrt bleibt.", "Wenden Sie Timeouts, Retries mit Backoff und Circuit-Breaker an, damit ein langsamer oder ausfallender Agent nicht den gesamten Job blockiert.", "Menschliche Aufsicht staffeln: Leichtere Überprüfung bei risikoarmen Jobs, obligatorische Approval Gates bei irreversiblen oder sensiblen Aufgaben." ], "examples": [ "Ein Recherche- und Berichtsworkflow, bei dem ein Supervisor das Sammeln, Synthetisieren und die QS zur Faktenprüfung an separate Agenten delegiert.", "Eine Pipeline für Kundenantworten, die Entwürfe erstellt, aber compliance-relevante Fälle an ein menschliches Approval Gate weiterleitet.", "Ein Operations-Backoffice-Team aus Agenten, die Tickets triagieren, Aktionen vorbereiten und Ausnahmen an Mitarbeiter eskalieren." ], "faqs": [ { "q": "Wie unterscheidet sich dies von einem einzelnen KI-Agenten?", "a": "Ein einzelner Agent übernimmt das gesamte Reasoning und die Tool-Nutzung selbst. Eine AI Workforce besteht aus vielen koordinierten Agenten unter einem Supervisor, der Ziele zerlegt, an Spezialisten delegiert, den Zustand teilt und das gesamte Team steuert. Die eigentlichen Herausforderungen liegen in der Koordination, der Verantwortlichkeit und dem Schadensradius (Blast Radius) und weniger in den Fähigkeiten eines einzelnen Agenten." }, { "q": "Führen mehr Agenten immer zu einem besseren System?", "a": "Nein. Jeder zusätzliche Agent bringt Übergaben, Latenz und neue Fehlerquellen mit sich. Fügen Sie Spezialisten nur dann hinzu, wenn ein einfacheres Team die Arbeit nachweislich nicht bewältigen kann, und messen Sie den Koordinationsaufwand, damit die Kosten der Orchestrierung nicht deren Nutzen übersteigen." }, { "q": "Wie messen wir echte Produktivitätssteigerungen?", "a": "Messen Sie End-to-End im Vergleich zu einer ehrlichen menschlichen Baseline: Erfolg der Aufgabe, Eskalation, Nacharbeit und Kosten pro abgeschlossener Aufgabe. Beschleunigungen auf Task-Ebene können nachgelagerte Korrekturen und Review-Zeiten verschleiern. Berücksichtigen Sie daher nur Gewinne, die einer vollständigen End-to-End-Evaluierung standhalten." } ] }, "ja": { "name": "AIワークフォース", "summary": "AIワークフォースとは、スーパーバイザー（監督者）のもとで、複数ステップのビジネスプロセスを協調して実行する、専門化されたエージェントのオーケストレーションされたチームです。スーパーバイザーは目標を分解し、優先順位を付けて、専門エージェント（調査、起草、QAなど）にサブタスクを委任します。各エージェントは共通のストアを介して状態（ステート）を共有します。エージェントは自身の能力を超える場合に人間へエスカレーションし、すべてのステップが観察可能（オブザーバブル）かつガバナンスの対象となります。これはデジタルワーカーの管理として捉えるべきです。成功するかどうかは、個々のエージェントの能力よりも、コーディネーション、エージェントレジストリによる明確な所有権、人間による監視、および個々のパーツではなくチーム全体を評価することにかかっています。", "keyConcepts": [ "1つのエージェントがすべてを行うのではなく、スーパーバイザーが目標を分解し、専門エージェントに委任します。", "共有状態とエージェントレジストリにより、チームにメモリ、明確な所有権、および検出可能な機能が提供されます。", "人間による監視、エスカレーション、およびガバナンスにより、エージェントが誤った行動をとった際の影響範囲（ブラスト半径）を制限します。", "ワークフォースを個々のエージェントとして切り離して評価するのではなく、1つのシステムとして評価および測定します。" ], "definition": "AIワークフォースアーキテクチャとは、統制されたマルチエージェントシステムであり、スーパーバイザーが目標を分解し、優先順位付けされたサブタスクを専門エージェントに委任します。これらのエージェントは状態を共有し、人間へのエスカレーションを行い、エンドツーエンドで観察されます。", "architecture": [ "その中心に位置するのが、ビジネス目標を受け取り、それをサブタスクの計画に分解し、優先順位を付け、それぞれを最適な専門エージェントにルーティングするスーパーバイザー（またはオーケストレーター）です。専門エージェント（調査、起草、QA、ツール実行エージェントなど）はエージェントレジストリに登録されます。このレジストリには、各エージェントの機能、入力、出力、コスト、および所有者が記録されるため、スーパーバイザーはそれらを検出して選択でき、人間はその振る舞いに対する責任の所在を明らかにできます。", "エージェントは、すべての情報をプロンプト経由で受け渡すわけではありません。進行中のジョブコンテキスト、中間成果物、および意思決定を保持する共有メモリまたは状態ストアの読み書きを行います。この共有状態こそが、単なるエージェントの集まりをチームへと変える要素です。ステップ間の連続性を維持し、エージェントが互いの成果を基に作業できるようにし、オブザーバビリティと監査に「信頼できる唯一の情報源（Single Source of Truth）」を提供します。エージェントとツールまたはデータの間にガードレールを配置することで、アクションを制限し、出力を検証し、安全でない操作を防止します。", "システム全体を包み込むのが、人間による監視とガバナンスです。定義されたエスカレーションパスにより、信頼度が低い場合やリスクの高いタスクにおいて、エージェントから人間へと処理を引き継ぐことができます。また、承認ゲートにより、取り返しのつかないアクションを実行する前に人間の承認を義務付けます。オブザーバビリティ（トレース、評価、エージェントごとおよびジョブごとのコストとレイテンシ）により、チームの振る舞いが可視化されます。1つのエージェントの失敗が連鎖する可能性があるため、このアーキテクチャでは、スコープ制限、タイムアウト、サーキットブレーカーを通じて、影響範囲（ブラスト半径）を意図的に制限します。" ], "flow": [ "1. インテーク（受付）: ビジネス目標またはジョブがシステムに入力され、スーパーバイザーがコンテキスト、優先順位、および所有権とともにそれを記録します。", "2. 分解と優先順位付け: スーパーバイザーは、依存関係と緊急度を考慮しながら、目標を順序付けされたサブタスクに分解し、ランク付けします。", "3. 委任: 各サブタスクは、機能とコストに基づいてエージェントレジストリから選択された専門エージェントにルーティングされます。", "4. 共有状態による実行: エージェントはガードレールで保護されたツールを使用して作業し、共有ストアの読み書きを行うことで、後続のエージェントが先行する結果を利用できるようにします。", "5. エスカレーションまたは承認: 信頼度が低い場合やリスクが高い場合、エージェントは人間にエスカレーションするか、承認ゲートで待機します。", "6. 統合、検証、およびクローズ: QAステップで統合された出力を検証し、スーパーバイザーがジョブを完了させ、評価用のトレースとメトリクスを出力します。" ], "components": [ "計画と委任を行うスーパーバイザー / オーケストレーター", "所有者と機能を管理する専門エージェントのエージェントレジストリ", "専門エージェント（調査、起草、QA、ツール実行）", "ジョブコンテキスト用の共有メモリ / 状態ストア", "ツール、データ、および出力に対するガードレール", "人間による監視: エスカレーションパスと承認ゲート", "ワークフォース全体のオブザーバビリティと評価" ], "referenceScenario": { "context": "中規模企業において、現在は人間が承認する前に調査ステップ、起草ステップ、およびコンプライアンスレビューを必要としている、顧客向けのポリシー回答の起草を自動化したいと考えています。", "scenario": "目標がシステムに入力されると、スーパーバイザーはそれを調査、起草、QAのサブタスクに分解し、それぞれを専門エージェントに委任します。また、コンプライアンスに影響するものはすべて、リリース前に人間による承認ゲートにルーティングします。", "technology": "マルチエージェントオーケストレーション用のLangGraph、機能検出と所有権管理用のエージェントレジストリ、ジョブコンテキスト用の共有状態ストア、検索とツールに対するガードレール、およびトレースと評価用のLangSmithまたはLangfuse。", "load": "週に数千件のジョブという想定ボリューム。営業時間中にスパイクが発生し、人間へのエスカレーションを必要とする複雑なジョブのロングテールが存在します。", "results": "ここに記載されているすべての数値は、ご自身の環境で計測・測定するための参照ターゲットであり、保証値ではありません。生産性の向上を主張する前に、エンドツーエンドのジョブ成功率、エスカレーション率、手戻り率、および完了ジョブあたりのコストを追跡し、人間の基準値（ベースライン）と比較して検証することを目指してください。" }, "benefits": [ "専門化により、1つのモノリシックなエージェントよりも、各エージェントをシンプルにし、適切に評価し、所有権を管理しやすくすることができます。", "優先順位付けを行うスーパーバイザーが、単一のエージェントでは順序立てて処理することが困難な、依存関係の多い複数ステップの作業を処理します。", "共有状態とレジストリにより、明確な所有権と検出可能な機能が提供され、チームの監査が可能になります。", "人間による監視とガバナンスにより、リスクを制限しながら段階的に自動化を導入できます。" ], "risks": [ "コーディネーションコストは非線形に増加します。エージェントやハンドオフが増えると、レイテンシが増加し、エラーが複合化する可能性があります。", "1つのエージェントのエラーがチーム全体に連鎖し、障害の影響範囲（ブラスト半径）が拡大する可能性があります。", "エージェントレジストリと明確な所有権がないと、振る舞いが不透明になり、責任の所在が曖昧になります。", "タスク単位で測定し、エンドツーエンドでの人間による実際の基準値（ベースライン）と比較しない場合、生産性の向上という主張は錯覚にすぎない可能性があります。" ], "failureModes": [ "連鎖的障害: 誤った中間結果が後続のプロセスで信頼され、最終的な出力を破損させます。", "コーディネーションのデッドロックまたはループ: エージェントが互いに待機し合ったり、同じサブタスクを無期限に再委任し合ったりします。", "共有状態の喪失または陳腐化: エージェントが古いコンテキストに基づいて動作し、一貫性のない結果を生成します。", "エスカレーションの欠落: エージェントが人間に引き継ぐべきリスクの高いタスクを、そのまま実行してしまいます。" ], "lessons": [ "まずは機能する最小限 of チームから開始し、単一のエージェントでは明らかに対処できない場合にのみ専門エージェントを追加します。", "エージェントレジストリ、所有権、および共有状態のコントラクトに早期に投資してください。これらがシステムを統制可能にする要素です。", "個々のエージェントだけでなく、ワークフォース全体をエンドツーエンドで評価してください。破綻が生じるのはコーディネーションの部分だからです。", "インシデントが発生した後にガバナンスを後付けするのではなく、初日からエスカレーションと影響範囲（ブラスト半径）の制限を設計してください。" ], "kpis": [ { "metric": "エンドツーエンドのジョブ成功率", "note": "人間の修正なしで正しく完了したジョブの割合。チームが実際に機能しているかどうかを示す主要な指標です。" }, { "metric": "エスカレーション率", "note": "人間に引き継がれたジョブの割合。高すぎる場合は自動化が不十分であることを意味し、低すぎる場合は安全でない過剰な自動化が行われている可能性があります。" }, { "metric": "手戻り / 修正率", "note": "出力が差し戻されたり修正されたりする頻度。手戻りの増加は、連鎖的なエラーや不十分なQAを示しています。" }, { "metric": "完了ジョブあたりのコスト", "note": "完了したジョブあたりのモデル、ツール、および人間によるレビューの総コスト。生産性向上の主張の背後にある、実際のユニットエコノミクスです。" }, { "metric": "コーディネーションオーバーヘッド", "note": "単一エージェントの基準値（ベースライン）と比較した、ハンドオフによる追加のレイテンシとトークンコスト。チームの規模に合わせて増加するため、監視が必要です。" } ], "scaling": [ "レジストリの配下に専門エージェントを追加することでスケールさせますが、追加するたびに評価すべき新たなコーディネーション領域（サーフェス）として扱ってください。", "共有状態の一貫性を維持しながら、独立したサブタスクが並行して実行されるように作業を分割します。", "タイムアウト、バックオフ付きリトライ、およびサーキットブレーカーを適用し、処理の遅いエージェントや失敗したエージェントがジョブ全体を停滞させないようにします。", "人間による監視を階層化します。リスクの低いジョブには軽めのレビューを、取り返しのつかないジョブや機密性の高いジョブには必須の承認ゲートを設けます。" ], "examples": [ "スーパーバイザーが収集、統合、およびファクトチェックQAをそれぞれ別個のエージェントに委任する、調査およびレポート作成のワークフロー。", "回答を起草するものの、コンプライアンスに影響するケースは人間による承認ゲートにルーティングする、顧客対応パイプライン。", "チケットのトリアージ、アクションの準備を行い、例外事項をスタッフにエスカレーションする、エージェントによるオペレーションバックオフィスチーム。" ], "faqs": [ { "q": "単一のAIエージェントと何が違うのですか？", "a": "単一のエージェントは、すべての推論とツールの使用を自身で行います。AIワークフォースは、スーパーバイザーのもとで協調して動作する複数のエージェントであり、スーパーバイザーが目標を分解し、専門エージェントに委任し、状態を共有し、チーム全体を統制します。ここでの困難な課題は、個々のエージェントの能力ではなく、コーディネーション、所有権、および影響範囲（ブラスト半径）の管理にあります。" }, { "q": "エージェントを増やせば、システムは常に向上しますか？", "a": "いいえ。エージェントを追加するたびに、ハンドオフ、レイテンシー、そして新たな障害要因が発生します。よりシンプルなチームでは明らかに業務を遂行できない場合にのみスペシャリストを追加し、オーケストレーションのコストがそのメリットを上回らないよう、調整オーバーヘッドを測定してください。" }, { "q": "実際の生産性向上はどのように測定すればよいですか？", "a": "業務の成功率、エスカレーション、手戻り、完了した業務あたりのコストなど、信頼できる人間の基準（ベースライン）と比較してエンドツーエンドで測定します。タスクごとの速度向上は、下流での修正やレビュー時間を隠蔽してしまう可能性があるため、完全なエンドツーエンドの評価をクリアした向上分のみをカウントしてください。" } ] }, "zh": { "name": "AI 员工", "summary": "AI 员工是由专业智能体协同组成的编排团队，在主管智能体的领导下协作处理多步骤业务流程。主管智能体负责分解目标，并将子任务按优先级分配给专业智能体（如研究、起草、QA），它们通过公共存储共享状态。当智能体能力不足时会升级上报给人类，且每个步骤都是可观测和受治理的。应将其视为管理数字化员工：成功较少取决于单个智能体，而更多取决于协同、通过智能体注册表确立的清晰权责归属、人类监督以及对整个团队而非局部进行评估。", "keyConcepts": [ "由主管智能体分解目标并分派给专业智能体，而不是由单个智能体包揽所有工作。", "共享状态和智能体注册表为团队提供了记忆、清晰的权责归属以及可发现的能力。", "人类监督、升级上报和治理机制可以在智能体行为失当时限制爆炸半径。", "您需要将 AI 员工作为一个系统进行评估和衡量，而不是孤立地评估每个智能体。" ], "definition": "AI 员工架构是一个受治理的多智能体系统，其中主管智能体负责分解目标，并将排好优先级的子任务分派给专业智能体。这些智能体共享状态、可升级上报给人类，并接受端到端的观测。", "architecture": [ "核心是一个主管（或编排器）智能体，它接收业务目标，将其分解为子任务计划，排列优先级，并将每个子任务路由给最适合的专业智能体。专业智能体（例如研究、起草、QA 和工具智能体）注册在智能体注册表中，该注册表记录了每个智能体的能力、输入、输出、成本和所有者，以便主管智能体进行发现和选择，并让人类对智能体行为进行问责。", "智能体并不完全通过提示词传递所有内容。它们读写共享内存或状态存储，其中保存着不断演进的任务上下文、中间产物和决策。这种共享状态将松散的智能体集合凝聚成一个团队：它保持了步骤之间的连续性，让智能体能够基于彼此的工作成果继续推进，并为可观测性和审计提供了单一可信源。护栏介于智能体与工具或数据之间，用以约束行为、验证输出并防止不安全的操作。", "人类监督和治理贯穿整个系统。明确的升级上报路径允许智能体在置信度较低或任务风险较高时移交给人类，而审批关卡则要求在执行不可逆操作之前获得人类的签字批准。可观测性（每个智能体和每个任务的追踪、评估、成本和延迟）使团队的行为清晰可见。由于单个智能体的故障可能会级联放大，该架构通过限制范围、设置超时和熔断器来刻意限制爆炸半径。" ], "flow": [ "1. 准入：业务目标或任务进入系统，主管智能体记录其上下文、优先级和所有权。", "2. 分解与排序：主管智能体将目标分解为有序的子任务，并结合依赖关系和紧急程度进行优先级排序。", "3. 分派：根据能力和成本，从智能体注册表中选择合适的专业智能体，并将每个子任务路由给它。", "4. 结合共享状态执行：智能体在受护栏保护的工具下工作，读写共享存储，以便后续智能体基于先前的结果继续构建。", "5. 升级或审批：当置信度较低或风险较高时，智能体会在审批关卡处等待，或升级上报给人类。", "6. 组装、验证与关闭：QA 步骤检查合并后的输出，主管智能体结束任务，并输出追踪和指标以供评估。" ], "components": [ "负责规划和分派的主管/编排器", "包含所有者和能力的专业智能体注册表", "专业智能体（研究、起草、QA、工具）", "用于任务上下文的共享内存/状态存储", "针对工具、数据和输出的护栏", "人类监督：升级上报路径和审批关卡", "贯穿整个 AI 员工队伍的可观测性与评估" ], "referenceScenario": { "context": "一家中型企业希望自动起草面向客户的政策答复，目前这需要经过研究、起草和合规审查步骤，最后由人工签字批准。", "scenario": "目标进入系统；主管智能体将其分解为研究、起草和 QA 子任务，分别分派给对应的专业智能体，并在发布前将任何涉及合规敏感的内容路由到人工审批关卡。", "technology": "使用 LangGraph 进行多智能体编排，使用智能体注册表进行能力发现和权责归属，使用共享状态存储保存任务上下文，针对检索和工具设置护栏，并使用 LangSmith 或 Langfuse 进行追踪和评估。", "load": "示例业务量为每周数千个任务，在工作时间会出现峰值，并存在大量需要人工升级处理的复杂长尾任务。", "results": "此处的所有数据均为在您自己的环境中进行检测和衡量的参考目标，并非保证：旨在跟踪端到端任务成功率、升级率、返工率以及每个已完成任务的成本，并在声称提高生产力之前对照人工基线进行验证。" }, "benefits": [ "专业化使得每个智能体比单体智能体更简单、更容易评估且更容易确定权责归属。", "具备优先级排序功能的主管智能体可以处理多步骤、充满依赖关系的工作，而单个智能体很难理清这些工作的顺序。", "共享状态和注册表使团队具备可审计性，拥有清晰的权责归属和可发现的能力。", "人类监督和治理让您能够在限制风险的同时，逐步引入自动化。" ], "risks": [ "协同成本呈非线性增长；更多的智能体和交接可能会增加延迟并导致错误累积。", "单个智能体中的错误可能会在整个团队中级联，从而扩大故障的爆炸半径。", "如果没有智能体注册表和清晰的权责归属，行为就会变得不透明，且无人负责。", "如果仅按单项任务衡量，而不是对照真实的端到端人工基线，那么关于生产力提升的说法可能是虚幻的。" ], "failureModes": [ "级联故障：错误的中间结果被下游信任，从而破坏了最终输出。", "协同死锁或循环：智能体相互等待，或无限期地重新分派同一个子任务。", "共享状态丢失或过期：智能体基于过时的上下文采取行动，导致输出结果不一致。", "升级遗漏：智能体继续执行高风险任务，而不是移交给人类。" ], "lessons": [ "从能够运转的最简团队开始，只有在证明单个智能体确实无法应对时，才增加专业智能体。", "尽早投入建设智能体注册表、权责归属和共享状态契约；这些是使系统可治理的关键所在。", "端到端地评估整个 AI 员工队伍，而不仅仅是单个智能体，因为协同往往是出现问题的地方。", "从第一天起就设计好升级机制和爆炸半径限制，而不是在发生事故后才强行加入治理机制。" ], "kpis": [ { "metric": "端到端任务成功率", "note": "无需人工纠正即可正确完成的任务比例；这是衡量团队是否真正发挥作用的首要指标。" }, { "metric": "升级率", "note": "移交给人类的任务比例；比例过高意味着自动化程度不足，过低则可能意味着存在不安全过度自动化的风险。" }, { "metric": "返工/纠正率", "note": "输出被退回或修正的频率；返工率上升标志着级联错误或 QA 环节薄弱。" }, { "metric": "每个已完成任务的成本", "note": "每个已完成任务的总模型、工具和人工审核成本；这是声称提高生产力背后的真实单体经济效益。" }, { "metric": "协同开销", "note": "与单智能体基线相比，因交接而增加的延迟和 Token 成本；需密切关注其随团队规模扩大而增长的情况。" } ], "scaling": [ "通过在注册表后添加专业智能体来进行扩展，但要将每次添加视为需要评估的新协同界面。", "对工作进行分区，使独立的子任务并行运行，同时保持共享状态的一致性。", "应用超时、带退避的重试以及熔断器，使缓慢或失败的智能体不会拖延整个任务。", "对人类监督进行分级：对低风险任务进行较轻的审核，对不可逆或敏感任务设置强制审批关卡。" ], "examples": [ "研究与报告工作流，其中主管智能体将收集、综合和事实核查 QA 分派给不同的智能体。", "客户回复流水线，负责起草回复，但将合规敏感的案例路由到人工审批关卡。", "由智能体组成的运营后台团队，负责对工单进行分类、准备行动，并将异常情况升级上报给员工。" ], "faqs": [ { "q": "这与单个 AI 智能体有什么不同？", "a": "单个智能体自身完成所有的推理和工具使用。而 AI 员工是在主管智能体领导下协同工作的多个智能体，主管智能体负责分解目标、分派给专业智能体、共享状态并治理整个团队；其难点在于协同、权责归属和爆炸半径，而不是单个智能体的能力。" }, { "q": "智能体数量越多，系统就一定会越好吗？", "a": "不一定。每增加一个智能体都会引入交接、延迟和新的故障点。只有在更简单的团队架构明显无法完成工作时，才引入专职智能体，并衡量协调开销，以确保编排成本不会超过其带来的收益。" }, { "q": "我们该如何衡量真正的生产力提升？", "a": "对照真实的人工基准进行端到端衡量：任务成功率、升级率、返工率以及单次完成任务的成本。单项任务的提速可能会掩盖下游的纠错和审核时间，因此只有在通过完整的端到端评估后，才能将这些提升计入收益。" } ] } } }, { "id": "ARCH-005", "slug": "operations-center", "category": "operations", "updated": "2026-06-21", "version": "1.0", "url": "https://santismm.com/en/architectures/operations-center", "api": "https://santismm.com/api/architectures/operations-center", "canonical_url": "https://santismm.com/en/architectures/operations-center", "api_url": "https://santismm.com/api/architectures/operations-center", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "medium", "sourceType": [ "industry_observation" ] }, "technologies": [ "Monitoring & alerting integration", "Runbook automation tools", "Incident management systems", "Human approval gates", "Guardrails", "Observability (LangSmith / Langfuse)" ], "patterns": [ "routing", "recovery-strategy", "human-escalation", "evaluator-optimizer", "human-approval-gate" ], "knowledge": [ "ai-agent", "tool-use", "ai-observability", "guardrails", "agentic-evaluation" ], "references": [ { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "Google SRE Book — Managing Incidents", "url": "https://sre.google/sre-book/managing-incidents/" } ], "related": [ "customer-service-agent", "ai-workforce" ], "locales": { "en": { "name": "Operations Center", "summary": "An operations center is an agentic AIOps system that watches monitoring signals and alerts, correlates and triages them, diagnoses likely root cause, and executes only vetted runbook remediations — keeping destructive or novel actions behind human approval. It cuts alert fatigue and shortens mean time to resolution by automating safe, read-mostly diagnostics while escalating risky writes to on-call engineers. Every action is audited and reversible. Success is measured honestly with MTTR, false-action rate, and escalation precision, not by automation volume.", "keyConcepts": [ "Read-mostly diagnostics run automatically; write or destructive actions require an explicit human approval gate.", "Alert correlation collapses noisy, redundant signals into a single incident to reduce fatigue.", "Remediation is bounded to vetted, versioned runbooks with safe rollback — never improvised actions.", "Every decision and action is captured in an immutable audit trail for review and learning." ], "definition": "The operations center architecture is an agentic AIOps pattern that triages alerts, diagnoses root cause, and runs only approved runbook remediations while gating risky actions behind human approval.", "architecture": [ "Signals enter through an ingestion and normalization layer that unifies metrics, logs, traces, and alerts from heterogeneous monitoring tools into a common event schema. A correlation engine groups related signals by service, time window, and dependency graph so that a single underlying fault surfaces as one incident rather than dozens of duplicate pages.", "A triage-and-diagnosis agent reasons over the correlated incident, pulls additional context through read-only tools (dashboards, recent deploys, topology, prior incidents), and proposes a likely root cause with a confidence estimate. A router classifies each incident by severity, blast radius, and whether a matching vetted runbook exists, then chooses between automated remediation, human approval, or direct escalation.", "Remediation executes through a guarded action layer where read-mostly steps run automatically but any write, restart, scale, or rollback passes a human approval gate. An evaluator checks outcomes against expected health signals and can trigger safe rollback. Observability and an immutable audit trail wrap every step, feeding a feedback loop that improves runbooks and routing over time." ], "flow": [ "1. A monitoring tool fires an alert; the ingestion layer normalizes it and the correlation engine merges it with related signals into one incident.", "2. The triage agent enriches the incident with read-only context — recent deploys, topology, dashboards, and similar past incidents.", "3. The diagnosis agent proposes a likely root cause with a confidence score and identifies whether a vetted runbook matches the symptom.", "4. The router decides the path: auto-run safe diagnostics, request human approval for write actions, or escalate novel or low-confidence cases to on-call.", "5. Approved remediation runs step by step from the runbook; the evaluator watches health signals and rolls back automatically if recovery fails.", "6. The incident is resolved or handed to a human, and the full timeline, decisions, and actions are written to the audit trail for review." ], "components": [ "Signal ingestion and normalization layer", "Alert correlation and deduplication engine", "Triage and root-cause diagnosis agent", "Severity and runbook router", "Guarded remediation layer with human approval gates", "Outcome evaluator with safe rollback", "Immutable audit trail and observability" ], "referenceScenario": { "context": "An illustrative mid-size SaaS provider runs dozens of microservices across two regions and is overwhelmed by redundant alerts during incidents, slowing response.", "scenario": "During a partial database failover, the operations center correlates a burst of latency, error-rate, and timeout alerts into a single incident, diagnoses a connection-pool exhaustion as the likely cause, runs read-only checks automatically, and requests human approval before recycling pool workers from a vetted runbook.", "technology": "Monitoring and alerting integrations feed a correlation engine and a triage agent; an incident management system tracks state; runbook automation executes approved steps; human approval gates and guardrails bound write actions; observability tooling captures traces.", "load": "Reference planning figures only: roughly 4,000 raw alerts per day collapsing to a few hundred incidents, with peak bursts of several hundred signals within minutes during major events.", "results": "Reference targets to measure, not guarantees: aim to reduce duplicate pages through correlation, shorten MTTR for runbook-covered incidents, and keep the false-action rate near zero by gating all writes. Validate every figure against your own baseline before relying on it." }, "benefits": [ "Correlation and deduplication sharply reduce alert fatigue and page volume for on-call staff.", "Automating safe, read-mostly diagnostics shortens mean time to resolution for well-understood incidents.", "Human approval gates keep destructive actions safe while still accelerating low-risk remediation.", "A complete audit trail improves postmortems, compliance, and continuous runbook improvement." ], "risks": [ "Over-trusting confidence scores can let a wrong diagnosis drive an inappropriate remediation.", "Automating beyond vetted runbooks risks novel, untested actions causing wider outages.", "Poorly tuned correlation can either merge unrelated incidents or fail to collapse duplicates.", "Approval-gate fatigue may push engineers to rubber-stamp requests without real review." ], "failureModes": [ "Alert storms overwhelm correlation, producing either one giant incident or a flood of fragments.", "A flawed runbook executes a harmful action that the evaluator fails to detect and roll back.", "The agent escalates everything, recreating the alert fatigue it was meant to remove.", "Stale topology or context data leads diagnosis toward the wrong root cause." ], "lessons": [ "Default to read-mostly automation and require human approval for every write or destructive action.", "Never auto-remediate beyond vetted, versioned runbooks with tested, safe rollback paths.", "Measure MTTR and false-action rate honestly rather than celebrating automation volume.", "Invest early in correlation quality; noisy incidents poison both diagnosis and human trust." ], "kpis": [ { "metric": "Mean time to resolution (MTTR)", "note": "Track separately for runbook-covered versus escalated incidents; good looks like a steady decline for covered cases without regressions elsewhere." }, { "metric": "False-action rate", "note": "Share of automated remediations that were wrong or harmful; good is near zero, sustained by tight write-action gating." }, { "metric": "Alert-to-incident compression", "note": "Ratio of raw alerts to correlated incidents; good means far fewer pages without hiding real distinct problems." }, { "metric": "Escalation precision", "note": "Fraction of escalations that genuinely needed a human; good avoids both over-escalation fatigue and missed risky cases." }, { "metric": "Rollback success rate", "note": "Share of failed remediations that rolled back cleanly to a safe state; good is consistently high with no lingering side effects." } ], "scaling": [ "Partition correlation and routing by service domain or region so incident volume scales horizontally.", "Keep runbooks versioned and independently testable so new automations can be added safely.", "Rate-limit and back-pressure ingestion to survive alert storms without losing audit fidelity.", "Expand automation coverage gradually, promoting runbooks from suggest-only to gated execution as confidence grows." ], "examples": [ "Correlating a deploy-triggered error spike into one incident and recommending a gated rollback of the latest release.", "Auto-running read-only disk, memory, and connection diagnostics, then requesting approval to recycle a saturated service.", "Escalating a novel, low-confidence networking anomaly directly to on-call with enriched context instead of guessing." ], "faqs": [ { "q": "Why not let the agent fix everything automatically?", "a": "Because destructive or novel actions can cause wider outages. The pattern automates safe, read-mostly diagnostics and gates every write behind human approval and a vetted runbook." }, { "q": "How does it reduce alert fatigue?", "a": "A correlation engine deduplicates and groups related signals into a single incident, so one underlying fault produces one page instead of dozens of redundant alerts." }, { "q": "What happens when a remediation goes wrong?", "a": "An evaluator compares outcomes to expected health signals and triggers a safe, tested rollback, while the full timeline is captured in the audit trail for postmortem review." } ] }, "es": { "name": "Centro de Operaciones", "summary": "Un centro de operaciones es un sistema agéntico de AIOps que vigila las señales de monitoreo y las alertas, las correlaciona y prioriza, diagnostica la causa raíz probable y ejecuta solo remediaciones de runbooks validados, manteniendo las acciones destructivas o novedosas detrás de una aprobación humana. Reduce la fatiga de alertas y acorta el tiempo medio de resolución automatizando diagnósticos seguros y de solo lectura, mientras escala las escrituras riesgosas a los ingenieros de guardia. Cada acción se audita y es reversible. El éxito se mide con honestidad mediante MTTR, tasa de acciones erróneas y precisión de escalado, no por volumen de automatización.", "keyConcepts": [ "Los diagnósticos de solo lectura se ejecutan automáticamente; las acciones de escritura o destructivas requieren una aprobación humana explícita.", "La correlación de alertas colapsa señales ruidosas y redundantes en un solo incidente para reducir la fatiga.", "La remediación se limita a runbooks validados y versionados con rollback seguro, nunca acciones improvisadas.", "Cada decisión y acción se registra en un rastro de auditoría inmutable para revisión y aprendizaje." ], "definition": "La arquitectura de centro de operaciones es un patrón agéntico de AIOps que prioriza alertas, diagnostica la causa raíz y ejecuta solo remediaciones de runbooks aprobados mientras coloca las acciones riesgosas detrás de una aprobación humana.", "architecture": [ "Las señales ingresan por una capa de ingesta y normalización que unifica métricas, logs, trazas y alertas de herramientas de monitoreo heterogéneas en un esquema de eventos común. Un motor de correlación agrupa las señales relacionadas por servicio, ventana temporal y grafo de dependencias, de modo que una sola falla subyacente aparezca como un único incidente en lugar de docenas de avisos duplicados.", "Un agente de priorización y diagnóstico razona sobre el incidente correlacionado, obtiene contexto adicional mediante herramientas de solo lectura (paneles, despliegues recientes, topología, incidentes previos) y propone una causa raíz probable con una estimación de confianza. Un enrutador clasifica cada incidente por severidad, radio de impacto y si existe un runbook validado que coincida, y luego elige entre remediación automatizada, aprobación humana o escalado directo.", "La remediación se ejecuta a través de una capa de acción protegida donde los pasos de solo lectura se ejecutan automáticamente, pero cualquier escritura, reinicio, escalado o rollback pasa por una aprobación humana. Un evaluador compara los resultados con las señales de salud esperadas y puede disparar un rollback seguro. La observabilidad y un rastro de auditoría inmutable envuelven cada paso, alimentando un bucle de retroalimentación que mejora los runbooks y el enrutamiento con el tiempo." ], "flow": [ "1. Una herramienta de monitoreo dispara una alerta; la capa de ingesta la normaliza y el motor de correlación la fusiona con señales relacionadas en un solo incidente.", "2. El agente de priorización enriquece el incidente con contexto de solo lectura: despliegues recientes, topología, paneles e incidentes pasados similares.", "3. El agente de diagnóstico propone una causa raíz probable con un puntaje de confianza e identifica si un runbook validado coincide con el síntoma.", "4. El enrutador decide el camino: ejecutar diagnósticos seguros automáticamente, solicitar aprobación humana para acciones de escritura, o escalar casos novedosos o de baja confianza a la guardia.", "5. La remediación aprobada se ejecuta paso a paso desde el runbook; el evaluador vigila las señales de salud y revierte automáticamente si la recuperación falla.", "6. El incidente se resuelve o se entrega a una persona, y la línea de tiempo completa, las decisiones y las acciones se escriben en el rastro de auditoría para su revisión." ], "components": [ "Capa de ingesta y normalización de señales", "Motor de correlación y deduplicación de alertas", "Agente de priorización y diagnóstico de causa raíz", "Enrutador de severidad y runbooks", "Capa de remediación protegida con aprobaciones humanas", "Evaluador de resultados con rollback seguro", "Rastro de auditoría inmutable y observabilidad" ], "referenceScenario": { "context": "Un proveedor SaaS de tamaño medio ilustrativo ejecuta docenas de microservicios en dos regiones y se ve abrumado por alertas redundantes durante los incidentes, lo que ralentiza la respuesta.", "scenario": "Durante una conmutación parcial de base de datos, el centro de operaciones correlaciona una ráfaga de alertas de latencia, tasa de error y timeouts en un solo incidente, diagnostica el agotamiento del pool de conexiones como causa probable, ejecuta verificaciones de solo lectura automáticamente y solicita aprobación humana antes de reciclar los workers del pool desde un runbook validado.", "technology": "Las integraciones de monitoreo y alertas alimentan un motor de correlación y un agente de priorización; un sistema de gestión de incidentes rastrea el estado; la automatización de runbooks ejecuta los pasos aprobados; las aprobaciones humanas y los guardrails limitan las acciones de escritura; las herramientas de observabilidad capturan trazas.", "load": "Solo cifras de planificación de referencia: aproximadamente 4.000 alertas crudas por día que colapsan en unos pocos cientos de incidentes, con picos de varios cientos de señales en minutos durante eventos mayores.", "results": "Objetivos de referencia para medir, no garantías: buscar reducir los avisos duplicados mediante la correlación, acortar el MTTR para incidentes cubiertos por runbooks y mantener la tasa de acciones erróneas cerca de cero limitando todas las escrituras. Valida cada cifra contra tu propia línea base antes de confiar en ella." }, "benefits": [ "La correlación y deduplicación reducen drásticamente la fatiga de alertas y el volumen de avisos para el personal de guardia.", "Automatizar los diagnósticos seguros y de solo lectura acorta el tiempo medio de resolución para incidentes bien comprendidos.", "Las aprobaciones humanas mantienen seguras las acciones destructivas mientras aceleran la remediación de bajo riesgo.", "Un rastro de auditoría completo mejora los postmortems, el cumplimiento y la mejora continua de los runbooks." ], "risks": [ "Confiar en exceso en los puntajes de confianza puede dejar que un diagnóstico erróneo impulse una remediación inapropiada.", "Automatizar más allá de los runbooks validados arriesga acciones novedosas y no probadas que causen interrupciones más amplias.", "Una correlación mal ajustada puede fusionar incidentes no relacionados o no colapsar los duplicados.", "La fatiga de las aprobaciones puede llevar a los ingenieros a aprobar sin un análisis real." ], "failureModes": [ "Las tormentas de alertas saturan la correlación, produciendo un incidente gigante o una avalancha de fragmentos.", "Un runbook defectuoso ejecuta una acción dañina que el evaluador no logra detectar ni revertir.", "El agente escala todo, recreando la fatiga de alertas que debía eliminar.", "Datos de topología o contexto desactualizados llevan el diagnóstico hacia la causa raíz equivocada." ], "lessons": [ "Predeterminar la automatización de solo lectura y exigir aprobación humana para cada acción de escritura o destructiva.", "Nunca remediar automáticamente más allá de runbooks validados y versionados con rutas de rollback probadas y seguras.", "Medir el MTTR y la tasa de acciones erróneas con honestidad en lugar de celebrar el volumen de automatización.", "Invertir temprano en la calidad de la correlación; los incidentes ruidosos envenenan tanto el diagnóstico como la confianza humana." ], "kpis": [ { "metric": "Tiempo medio de resolución (MTTR)", "note": "Medirlo por separado para incidentes cubiertos por runbooks frente a escalados; lo bueno es un descenso sostenido en los casos cubiertos sin regresiones en otros." }, { "metric": "Tasa de acciones erróneas", "note": "Proporción de remediaciones automatizadas que fueron incorrectas o dañinas; lo bueno es cercano a cero, sostenido por un control estricto de las escrituras." }, { "metric": "Compresión de alertas a incidentes", "note": "Relación entre alertas crudas e incidentes correlacionados; lo bueno significa muchos menos avisos sin ocultar problemas reales distintos." }, { "metric": "Precisión de escalado", "note": "Fracción de escalados que realmente necesitaban un humano; lo bueno evita tanto la fatiga por sobre-escalado como los casos riesgosos omitidos." }, { "metric": "Tasa de éxito de rollback", "note": "Proporción de remediaciones fallidas que revirtieron limpiamente a un estado seguro; lo bueno es consistentemente alto sin efectos secundarios persistentes." } ], "scaling": [ "Particionar la correlación y el enrutamiento por dominio de servicio o región para que el volumen de incidentes escale horizontalmente.", "Mantener los runbooks versionados y comprobables de forma independiente para que las nuevas automatizaciones se añadan con seguridad.", "Limitar la tasa y aplicar contrapresión en la ingesta para sobrevivir a las tormentas de alertas sin perder fidelidad de auditoría.", "Ampliar la cobertura de automatización gradualmente, promoviendo runbooks de solo sugerencia a ejecución controlada a medida que crece la confianza." ], "examples": [ "Correlacionar un pico de errores provocado por un despliegue en un solo incidente y recomendar un rollback controlado de la última versión.", "Ejecutar automáticamente diagnósticos de solo lectura de disco, memoria y conexiones, y luego solicitar aprobación para reciclar un servicio saturado.", "Escalar una anomalía de red novedosa y de baja confianza directamente a la guardia con contexto enriquecido en lugar de adivinar." ], "faqs": [ { "q": "¿Por qué no dejar que el agente lo arregle todo automáticamente?", "a": "Porque las acciones destructivas o novedosas pueden causar interrupciones más amplias. El patrón automatiza diagnósticos seguros y de solo lectura y coloca cada escritura detrás de una aprobación humana y un runbook validado." }, { "q": "¿Cómo reduce la fatiga de alertas?", "a": "Un motor de correlación deduplica y agrupa señales relacionadas en un solo incidente, de modo que una falla subyacente produce un aviso en lugar de docenas de alertas redundantes." }, { "q": "¿Qué ocurre cuando una remediación sale mal?", "a": "Un evaluador compara los resultados con las señales de salud esperadas y dispara un rollback seguro y probado, mientras la línea de tiempo completa queda registrada en el rastro de auditoría para el postmortem." } ] }, "pt": { "name": "Centro de Operações", "summary": "Um centro de operações é um sistema agêntico de AIOps que observa sinais de monitoramento e alertas, correlaciona e prioriza, diagnostica a causa raiz provável e executa apenas remediações de runbooks validados, mantendo ações destrutivas ou inéditas atrás de uma aprovação humana. Ele reduz a fadiga de alertas e encurta o tempo médio de resolução automatizando diagnósticos seguros e somente de leitura, enquanto escala as gravações arriscadas para os engenheiros de plantão. Cada ação é auditada e reversível. O sucesso é medido com honestidade por MTTR, taxa de ações erradas e precisão de escalonamento, não por volume de automação.", "keyConcepts": [ "Os diagnósticos somente de leitura rodam automaticamente; ações de gravação ou destrutivas exigem uma aprovação humana explícita.", "A correlação de alertas colapsa sinais ruidosos e redundantes em um único incidente para reduzir a fadiga.", "A remediação é limitada a runbooks validados e versionados com rollback seguro, nunca ações improvisadas.", "Cada decisão e ação é registrada em uma trilha de auditoria imutável para revisão e aprendizado." ], "definition": "A arquitetura de centro de operações é um padrão agêntico de AIOps que prioriza alertas, diagnostica a causa raiz e executa apenas remediações de runbooks aprovados enquanto coloca as ações arriscadas atrás de uma aprovação humana.", "architecture": [ "Os sinais entram por uma camada de ingestão e normalização que unifica métricas, logs, traces e alertas de ferramentas de monitoramento heterogêneas em um esquema de eventos comum. Um motor de correlação agrupa os sinais relacionados por serviço, janela de tempo e grafo de dependências, de modo que uma única falha subjacente apareça como um único incidente em vez de dezenas de avisos duplicados.", "Um agente de triagem e diagnóstico raciocina sobre o incidente correlacionado, busca contexto adicional por meio de ferramentas somente de leitura (painéis, deploys recentes, topologia, incidentes anteriores) e propõe uma causa raiz provável com uma estimativa de confiança. Um roteador classifica cada incidente por severidade, raio de impacto e se existe um runbook validado correspondente, e então escolhe entre remediação automatizada, aprovação humana ou escalonamento direto.", "A remediação é executada por uma camada de ação protegida onde os passos somente de leitura rodam automaticamente, mas qualquer gravação, reinício, escalonamento ou rollback passa por uma aprovação humana. Um avaliador compara os resultados com os sinais de saúde esperados e pode disparar um rollback seguro. A observabilidade e uma trilha de auditoria imutável envolvem cada passo, alimentando um ciclo de retroalimentação que melhora os runbooks e o roteamento ao longo do tempo." ], "flow": [ "1. Uma ferramenta de monitoramento dispara um alerta; a camada de ingestão o normaliza e o motor de correlação o funde com sinais relacionados em um único incidente.", "2. O agente de triagem enriquece o incidente com contexto somente de leitura: deploys recentes, topologia, painéis e incidentes passados semelhantes.", "3. O agente de diagnóstico propõe uma causa raiz provável com uma pontuação de confiança e identifica se um runbook validado corresponde ao sintoma.", "4. O roteador decide o caminho: rodar diagnósticos seguros automaticamente, pedir aprovação humana para ações de gravação, ou escalar casos inéditos ou de baixa confiança para o plantão.", "5. A remediação aprovada roda passo a passo a partir do runbook; o avaliador observa os sinais de saúde e reverte automaticamente se a recuperação falhar.", "6. O incidente é resolvido ou entregue a uma pessoa, e a linha do tempo completa, as decisões e as ações são gravadas na trilha de auditoria para revisão." ], "components": [ "Camada de ingestão e normalização de sinais", "Motor de correlação e deduplicação de alertas", "Agente de triagem e diagnóstico de causa raiz", "Roteador de severidade e runbooks", "Camada de remediação protegida com aprovações humanas", "Avaliador de resultados com rollback seguro", "Trilha de auditoria imutável e observabilidade" ], "referenceScenario": { "context": "Um provedor SaaS de médio porte ilustrativo roda dezenas de microsserviços em duas regiões e é sobrecarregado por alertas redundantes durante incidentes, o que atrasa a resposta.", "scenario": "Durante um failover parcial de banco de dados, o centro de operações correlaciona uma rajada de alertas de latência, taxa de erro e timeouts em um único incidente, diagnostica o esgotamento do pool de conexões como causa provável, roda verificações somente de leitura automaticamente e pede aprovação humana antes de reciclar os workers do pool a partir de um runbook validado.", "technology": "As integrações de monitoramento e alertas alimentam um motor de correlação e um agente de triagem; um sistema de gestão de incidentes acompanha o estado; a automação de runbooks executa os passos aprovados; as aprovações humanas e os guardrails limitam as ações de gravação; as ferramentas de observabilidade capturam traces.", "load": "Apenas números de planejamento de referência: cerca de 4.000 alertas brutos por dia colapsando em poucas centenas de incidentes, com picos de várias centenas de sinais em minutos durante eventos maiores.", "results": "Metas de referência para medir, não garantias: buscar reduzir os avisos duplicados por meio da correlação, encurtar o MTTR para incidentes cobertos por runbooks e manter a taxa de ações erradas perto de zero limitando todas as gravações. Valide cada número contra sua própria linha de base antes de confiar nele." }, "benefits": [ "A correlação e a deduplicação reduzem drasticamente a fadiga de alertas e o volume de avisos para o pessoal de plantão.", "Automatizar os diagnósticos seguros e somente de leitura encurta o tempo médio de resolução para incidentes bem compreendidos.", "As aprovações humanas mantêm as ações destrutivas seguras enquanto aceleram a remediação de baixo risco.", "Uma trilha de auditoria completa melhora os postmortems, a conformidade e a melhoria contínua dos runbooks." ], "risks": [ "Confiar demais nas pontuações de confiança pode deixar um diagnóstico errado conduzir uma remediação inadequada.", "Automatizar além dos runbooks validados arrisca ações inéditas e não testadas que causem interrupções mais amplas.", "Uma correlação mal ajustada pode fundir incidentes não relacionados ou não colapsar os duplicados.", "A fadiga das aprovações pode levar os engenheiros a aprovar sem uma análise real." ], "failureModes": [ "Tempestades de alertas sobrecarregam a correlação, produzindo um incidente gigante ou uma enxurrada de fragmentos.", "Um runbook defeituoso executa uma ação prejudicial que o avaliador não consegue detectar nem reverter.", "O agente escala tudo, recriando a fadiga de alertas que deveria eliminar.", "Dados de topologia ou contexto desatualizados levam o diagnóstico para a causa raiz errada." ], "lessons": [ "Adotar por padrão a automação somente de leitura e exigir aprovação humana para cada ação de gravação ou destrutiva.", "Nunca remediar automaticamente além de runbooks validados e versionados com caminhos de rollback testados e seguros.", "Medir o MTTR e a taxa de ações erradas com honestidade em vez de comemorar o volume de automação.", "Investir cedo na qualidade da correlação; incidentes ruidosos envenenam tanto o diagnóstico quanto a confiança humana." ], "kpis": [ { "metric": "Tempo médio de resolução (MTTR)", "note": "Medir separadamente para incidentes cobertos por runbooks versus escalados; o bom é uma queda sustentada nos casos cobertos sem regressões em outros." }, { "metric": "Taxa de ações erradas", "note": "Proporção de remediações automatizadas que foram incorretas ou prejudiciais; o bom é perto de zero, sustentado por um controle rígido das gravações." }, { "metric": "Compressão de alertas em incidentes", "note": "Relação entre alertas brutos e incidentes correlacionados; o bom significa muito menos avisos sem ocultar problemas reais distintos." }, { "metric": "Precisão de escalonamento", "note": "Fração de escalonamentos que realmente precisavam de um humano; o bom evita tanto a fadiga por escalonamento excessivo quanto os casos arriscados omitidos." }, { "metric": "Taxa de sucesso de rollback", "note": "Proporção de remediações falhas que reverteram de forma limpa para um estado seguro; o bom é consistentemente alto, sem efeitos colaterais persistentes." } ], "scaling": [ "Particionar a correlação e o roteamento por domínio de serviço ou região para que o volume de incidentes escale horizontalmente.", "Manter os runbooks versionados e testáveis de forma independente para que novas automações sejam adicionadas com segurança.", "Limitar a taxa e aplicar contrapressão na ingestão para sobreviver a tempestades de alertas sem perder fidelidade de auditoria.", "Ampliar a cobertura de automação gradualmente, promovendo runbooks de apenas sugestão para execução controlada à medida que a confiança cresce." ], "examples": [ "Correlacionar um pico de erros provocado por um deploy em um único incidente e recomendar um rollback controlado da última versão.", "Rodar automaticamente diagnósticos somente de leitura de disco, memória e conexões e, em seguida, pedir aprovação para reciclar um serviço saturado.", "Escalar uma anomalia de rede inédita e de baixa confiança diretamente para o plantão com contexto enriquecido em vez de adivinhar." ], "faqs": [ { "q": "Por que não deixar o agente corrigir tudo automaticamente?", "a": "Porque ações destrutivas ou inéditas podem causar interrupções mais amplas. O padrão automatiza diagnósticos seguros e somente de leitura e coloca cada gravação atrás de uma aprovação humana e de um runbook validado." }, { "q": "Como ele reduz a fadiga de alertas?", "a": "Um motor de correlação deduplica e agrupa sinais relacionados em um único incidente, de modo que uma falha subjacente produz um aviso em vez de dezenas de alertas redundantes." }, { "q": "O que acontece quando uma remediação dá errado?", "a": "Um avaliador compara os resultados com os sinais de saúde esperados e dispara um rollback seguro e testado, enquanto a linha do tempo completa fica registrada na trilha de auditoria para o postmortem." } ] }, "fr": { "name": "Centre d'opérations", "summary": "Un centre d'opérations est un système d'AIOps agentique qui surveille les signaux et alertes de monitoring, les corrèle et les trie, diagnostique la cause racine probable et exécute uniquement des remédiations de runbook validées — tout en soumettant les actions destructrices ou inédites à une approbation humaine. Il réduit la fatigue liée aux alertes et raccourcit le temps moyen de résolution (MTTR) en automatisant des diagnostics sûrs, principalement en lecture seule, tout en escaladant les écritures risquées vers les ingénieurs d'astreinte. Chaque action est auditée et réversible. Le succès est mesuré de manière honnête à l'aide du MTTR, du taux de fausses actions et de la précision de l'escalade, et non par le volume d'automatisation.", "keyConcepts": [ "Les diagnostics principalement en lecture seule s'exécutent automatiquement ; les actions d'écriture ou destructrices nécessitent une étape d'approbation humaine explicite.", "La corrélation d'alertes regroupe les signaux bruyants et redondants en un seul incident afin de réduire la fatigue.", "La remédiation est limitée à des runbooks validés et versionnés avec un retour arrière (rollback) sécurisé — jamais d'actions improvisées.", "Chaque décision et action est consignée dans une piste d'audit immuable pour examen et apprentissage." ], "definition": "L'architecture du centre d'opérations est un modèle d'AIOps agentique qui trie les alertes, diagnostique la cause racine et exécute uniquement des remédiations de runbook approuvées, tout en soumettant les actions risquées à une approbation humaine.", "architecture": [ "Les signaux entrent par une couche d'ingestion et de normalisation qui unifie les métriques, les journaux (logs), les traces et les alertes provenant d'outils de monitoring hétérogènes dans un schéma d'événements commun. Un moteur de corrélation regroupe les signaux associés par service, fenêtre temporelle et graphe de dépendances, de sorte qu'une seule faille sous-jacente apparaisse comme un incident unique plutôt que sous la forme de dizaines d'alertes redondantes.", "Un agent de tri et de diagnostic analyse l'incident corrélé, extrait du contexte supplémentaire via des outils en lecture seule (tableaux de bord, déploiements récents, topologie, incidents antérieurs) et propose une cause racine probable avec une estimation de confiance. Un routeur classifie chaque incident par gravité, rayon d'impact (blast radius) et existence d'un runbook validé correspondant, puis choisit entre la remédiation automatisée, l'approbation humaine ou l'escalade directe.", "La remédiation s'exécute via une couche d'action sécurisée où les étapes principalement en lecture seule s'exécutent automatiquement, mais où toute action d'écriture, de redémarrage, de mise à l'échelle (scaling) ou de retour arrière passe par une étape d'approbation humaine. Un évaluateur vérifie les résultats par rapport aux signaux d'état de santé attendus et peut déclencher un retour arrière sécurisé. L'observabilité et une piste d'audit immuable encadrent chaque étape, alimentant une boucle de rétroaction qui améliore les runbooks et le routage au fil du temps." ], "flow": [ "1. Un outil de monitoring déclenche une alerte ; la couche d'ingestion la normalise et le moteur de corrélation la fusionne avec les signaux associés en un seul incident.", "2. L'agent de tri enrichit l'incident avec un contexte en lecture seule — déploiements récents, topologie, tableaux de bord et incidents passés similaires.", "3. L'agent de diagnostic propose une cause racine probable avec un score de confiance et identifie si un runbook validé correspond au symptôme.", "4. Le routeur décide du chemin : exécuter automatiquement des diagnostics sûrs, demander une approbation humaine pour les actions d'écriture, ou escalader les cas inédits ou à faible confiance vers l'astreinte.", "5. La remédiation approuvée s'exécute étape par étape à partir du runbook ; l'évaluateur surveille les signaux d'état de santé et effectue un retour arrière automatique si la récupération échoue.", "6. L'incident est résolu ou confié à un humain, et l'historique complet, les décisions et les actions sont consignés dans la piste d'audit pour examen." ], "components": [ "Couche d'ingestion et de normalisation des signaux", "Moteur de corrélation et de déduplication des alertes", "Agent de tri et de diagnostic de cause racine", "Routeur de gravité et de runbook", "Couche de remédiation sécurisée avec étapes d'approbation humaine", "Évaluateur de résultats avec retour arrière sécurisé", "Piste d'audit immuable et observabilité" ], "referenceScenario": { "context": "Un fournisseur SaaS de taille moyenne fictif exécute des dizaines de microservices sur deux régions et se retrouve submergé par des alertes redondantes lors des incidents, ce qui ralentit la réponse.", "scenario": "Lors d'un basculement (failover) partiel de base de données, le centre d'opérations corrèle une vague d'alertes de latence, de taux d'erreur et de dépassement de délai (timeout) en un seul incident, diagnostique une saturation du pool de connexions comme cause probable, exécute automatiquement des vérifications en lecture seule et demande une approbation humaine avant de redémarrer les processus de pool (pool workers) à partir d'un runbook validé.", "technology": "Les intégrations de monitoring et d'alerte alimentent un moteur de corrélation et un agent de tri ; un système de gestion des incidents suit l'état ; l'automatisation des runbooks exécute les étapes approuvées ; des étapes d'approbation humaine et des garde-fous encadrent les actions d'écriture ; les outils d'observabilité capturent les traces.", "load": "Chiffres de planification de référence uniquement : environ 4 000 alertes brutes par jour regroupées en quelques centaines d'incidents, avec des pics de plusieurs centaines de signaux en quelques minutes lors d'événements majeurs.", "results": "Objectifs de référence à mesurer, non contractuels : viser à réduire les alertes redondantes grâce à la corrélation, raccourcir le MTTR pour les incidents couverts par les runbooks et maintenir le taux de fausses actions proche de zéro en soumettant toutes les écritures à approbation. Valisez chaque chiffre par rapport à vos propres références avant de vous y fier." }, "benefits": [ "La corrélation et la déduplication réduisent considérablement la fatigue liée aux alertes et le volume d'appels pour le personnel d'astreinte.", "L'automatisation de diagnostics sûrs, principalement en lecture seule, raccourcit le temps moyen de résolution pour les incidents bien compris.", "Les étapes d'approbation humaine sécurisent les actions destructrices tout en accélérant la remédiation à faible risque.", "Une piste d'audit complète améliore les post-mortems, la conformité et l'amélioration continue des runbooks." ], "risks": [ "Une confiance excessive dans les scores de confiance peut conduire un diagnostic erroné à déclencher une remédiation inappropriée.", "Automatiser au-delà des runbooks validés présente le risque que des actions inédites et non testées provoquent des pannes plus étendues.", "Une corrélation mal ajustée peut soit fusionner des incidents sans rapport, soit échouer à regrouper les doublons.", "La fatigue liée aux étapes d'approbation peut inciter les ingénieurs à valider aveuglément les demandes sans examen réel." ], "failureModes": [ "Les tempêtes d'alertes submergent la corrélation, produisant soit un seul incident géant, soit un flux de fragments.", "Un runbook défectueux exécute une action nuisible que l'évaluateur ne parvient pas à détecter et à annuler.", "L'agent escalade tout, recréant ainsi la fatigue liée aux alertes qu'il était censé éliminer.", "Des données de topologie ou de contexte obsolètes orientent le diagnostic vers une mauvaise cause racine." ], "lessons": [ "Privilégiez par défaut l'automatisation en lecture seule et exigez une approbation humaine pour chaque action d'écriture ou destructrice.", "N'automatisez jamais la remédiation au-delà de runbooks validés et versionnés dotés de chemins de retour arrière testés et sûrs.", "Mesurez le MTTR et le taux de fausses actions de manière honnête plutôt que de célébrer le volume d'automatisation.", "Investissez tôt dans la qualité de la corrélation ; les incidents bruyants nuisent à la fois au diagnostic et à la confiance humaine." ], "kpis": [ { "metric": "Temps moyen de résolution (MTTR)", "note": "À suivre séparément pour les incidents couverts par un runbook et ceux escaladés ; un bon résultat se traduit par une baisse constante pour les cas couverts sans régression ailleurs." }, { "metric": "Taux de fausses actions", "note": "Part des remédiations automatisées qui étaient erronées ou nuisibles ; un bon résultat est proche de zéro, maintenu par un contrôle strict des actions d'écriture." }, { "metric": "Compression des alertes en incidents", "note": "Ratio entre les alertes brutes et les incidents corrélés ; un bon résultat signifie beaucoup moins d'appels d'astreinte sans pour autant masquer les problèmes distincts réels." }, { "metric": "Précision de l'escalade", "note": "Fraction des escalations qui nécessitaient réellement une intervention humaine ; un bon résultat évite à la fois la fatigue liée à la sur-escalade et l'omission de cas risqués." }, { "metric": "Taux de réussite du retour arrière", "note": "Part des remédiations ayant échoué qui ont fait l'objet d'un retour arrière propre vers un état sûr ; un bon résultat est constamment élevé, sans effets secondaires persistants." } ], "scaling": [ "Partitionnez la corrélation et le routage par domaine de service ou par région afin que le volume d'incidents évolue horizontalement.", "Conservez les runbooks versionnés et testables de manière indépendante afin que de nouvelles automatisations puissent être ajoutées en toute sécurité.", "Limitez le débit (rate-limit) et appliquez une contre-pression (back-pressure) sur l'ingestion pour survivre aux tempêtes d'alertes sans perdre la fidélité de l'audit.", "Étendez progressivement la couverture de l'automatisation, en faisant passer les runbooks d'un mode de suggestion uniquement à une exécution contrôlée à mesure que la confiance grandit." ], "examples": [ "Corréler un pic d'erreurs déclenché par un déploiement en un seul incident et recommander un retour arrière contrôlé de la dernière version.", "Exécuter automatiquement des diagnostics en lecture seule sur le disque, la mémoire et les connexions, puis demander l'approbation pour redémarrer un service saturé.", "Escalader directement une anomalie réseau inédite et à faible confiance vers l'astreinte avec un contexte enrichi au lieu de faire des suppositions." ], "faqs": [ { "q": "Pourquoi ne pas laisser l'agent tout corriger automatiquement ?", "a": "Parce que des actions destructrices ou inédites peuvent provoquer des pannes plus étendues. Ce modèle automatise les diagnostics sécurisés, principalement en lecture seule, et conditionne chaque écriture à une approbation humaine et à un runbook validé." }, { "q": "Comment réduit-il la fatigue liée aux alertes ?", "a": "Un moteur de corrélation déduplique et regroupe les signaux associés au sein d'un incident unique, de sorte qu'une seule défaillance sous-jacente génère une seule notification au lieu de dizaines d'alertes redondantes." }, { "q": "Que se passe-t-il lorsqu'une remédiation échoue ?", "a": "Un évaluateur compare les résultats aux signaux d'état attendus et déclenche un retour arrière (rollback) sécurisé et testé, tandis que l'historique complet est consigné dans la piste d'audit pour analyse post-mortem." } ] }, "de": { "name": "Operations Center", "summary": "Ein Operations Center ist ein agentisches AIOps-System, das Monitoring-Signale und Warnmeldungen überwacht, diese korreliert und triagiert, die wahrscheinliche Ursache diagnostiziert und ausschließlich geprüfte Runbook-Fehlerbehebungen ausführt – wobei destruktive oder neuartige Aktionen der menschlichen Freigabe vorbehalten bleiben. Es reduziert die Alarmmüdigkeit und verkürzt die mittlere Zeit bis zur Behebung (MTTR), indem es sichere, primär lesende Diagnosen automatisiert, während riskante Schreibvorgänge an On-Call-Ingenieure eskaliert werden. Jede Aktion ist auditierbar und umkehrbar. Der Erfolg wird ehrlich anhand von MTTR, der Rate fehlerhafter Aktionen und der Eskalationspräzision gemessen, nicht am Automatisierungsvolumen.", "keyConcepts": [ "Primär lesende Diagnosen laufen automatisch ab; schreibende oder destruktive Aktionen erfordern eine explizite menschliche Freigabe.", "Die Alarmkorrelation fasst verrauschte, redundante Signale zu einem einzigen Vorfall zusammen, um die Alarmmüdigkeit zu reduzieren.", "Die Fehlerbehebung ist auf geprüfte, versionierte Runbooks mit sicherem Rollback beschränkt – niemals auf improvisierte Aktionen.", "Jede Entscheidung und Aktion wird in einem unveränderlichen Audit-Trail zur Überprüfung und zum Lernen erfasst." ], "definition": "Die Operations-Center-Architektur ist ein agentisches AIOps-Muster, das Alarme triagiert, die Ursache diagnostiziert und nur genehmigte Runbook-Fehlerbehebungen ausführt, während riskante Aktionen von einer menschlichen Freigabe abhängen.", "architecture": [ "Signale gehen über eine Ingestions- und Normalisierungsschicht ein, die Metriken, Protokolle, Traces und Alarme aus heterogenen Monitoring-Tools in einem gemeinsamen Ereignisschema vereinheitlicht. Eine Korrelations-Engine gruppiert zusammengehörige Signale nach Dienst, Zeitfenster und Abhängigkeitsdiagramm, sodass ein einzelner zugrunde liegender Fehler als ein einziger Vorfall und nicht als Dutzende von doppelten Benachrichtigungen erscheint.", "Ein Triage- und Diagnose-Agent analysiert den korrelierten Vorfall, zieht zusätzlichen Kontext über schreibgeschützte Tools (Dashboards, aktuelle Deployments, Topologie, frühere Vorfälle) heran und schlägt eine wahrscheinliche Ursache mit einer Konfidenzschätzung vor. Ein Router klassifiziert jeden Vorfall nach Schweregrad, Auswirkung (Blast Radius) und dem Vorhandensein eines passenden, geprüften Runbooks und wählt dann zwischen automatisierter Fehlerbehebung, menschlicher Freigabe oder direkter Eskalation.", "Die Fehlerbehebung wird über eine geschützte Aktionsschicht ausgeführt, in der primär lesende Schritte automatisch ablaufen, aber jeder Schreibvorgang, Neustart, jede Skalierung oder jeder Rollback eine menschliche Freigabe erfordert. Ein Evaluator gleicht die Ergebnisse mit den erwarteten Zustandssignalen ab und kann einen sicheren Rollback auslösen. Observability und ein unveränderlicher Audit-Trail begleiten jeden Schritt und speisen eine Feedbackschleife, die Runbooks und Routing im Laufe der Zeit verbessert." ], "flow": [ "1. Ein Monitoring-Tool löst einen Alarm aus; die Ingestionsschicht normalisiert diesen und die Korrelations-Engine führt ihn mit zusammenhängenden Signalen zu einem einzigen Vorfall zusammen.", "2. Der Triage-Agent reichert den Vorfall mit schreibgeschütztem Kontext an – aktuelle Deployments, Topologie, Dashboards und ähnliche vergangene Vorfälle.", "3. Der Diagnose-Agent schlägt eine wahrscheinliche Ursache mit einem Konfidenzwert vor und prüft, ob ein geprüftes Runbook zum Symptom passt.", "4. Der Router entscheidet über den Pfad: automatische Ausführung sicherer Diagnosen, Anforderung einer menschlichen Freigabe für Schreibvorgänge oder Eskalation neuartiger Fälle oder solcher mit geringer Konfidenz an das On-Call-Team.", "5. Die genehmigte Fehlerbehebung wird Schritt für Schritt aus dem Runbook ausgeführt; der Evaluator überwacht die Zustandssignale und führt bei einer fehlschlagenden Wiederherstellung automatisch einen Rollback durch.", "6. Der Vorfall wird gelöst oder an einen Menschen übergeben, und die gesamte Timeline, Entscheidungen und Aktionen werden zur Überprüfung in den Audit-Trail geschrieben." ], "components": [ "Signal-Ingestions- und Normalisierungsschicht", "Alarmkorrelations- und Deduplizierungs-Engine", "Triage- und Ursachendiagnose-Agent", "Schweregrad- und Runbook-Router", "Geschützte Fehlerbehebungsschicht mit menschlichen Freigabestufen", "Ergebnis-Evaluator mit sicherem Rollback", "Unveränderlicher Audit-Trail und Observability" ], "referenceScenario": { "context": "Ein beispielhafter mittelgroßer SaaS-Anbieter betreibt Dutzende von Microservices in zwei Regionen und wird bei Vorfällen von redundanten Alarmen überflutet, was die Reaktion verlangsamt.", "scenario": "Während eines partiellen Datenbank-Failovers korreliert das Operations Center eine Flut von Latenz-, Fehlerraten- und Timeout-Alarmen zu einem einzigen Vorfall, diagnostiziert eine Erschöpfung des Connection-Pools als wahrscheinliche Ursache, führt automatisch schreibgeschützte Prüfungen durch und fordert eine menschliche Freigabe an, bevor Pool-Worker anhand eines geprüften Runbooks neu gestartet werden.", "technology": "Monitoring- und Alerting-Integrationen speisen eine Korrelations-Engine und einen Triage-Agenten; ein Incident-Management-System verfolgt den Zustand; Runbook-Automatisierung führt genehmigte Schritte aus; menschliche Freigabestufen und Guardrails begrenzen Schreibvorgänge; Observability-Tools erfassen Traces.", "load": "Nur Referenz-Planungszahlen: ca. 4.000 Rohalarme pro Tag, die auf einige hundert Vorfälle komprimiert werden, mit Spitzenwerten von mehreren hundert Signalen innerhalb von Minuten bei größeren Ereignissen.", "results": "Zu messende Referenzziele, keine Garantien: Ziel ist es, doppelte Benachrichtigungen durch Korrelation zu reduzieren, die MTTR für durch Runbooks abgedeckte Vorfälle zu verkürzen und die Rate fehlerhafter Aktionen durch die Freigabepflicht aller Schreibvorgänge nahe Null zu halten. Validieren Sie jede Zahl anhand Ihrer eigenen Baseline, bevor Sie sich darauf verlassen." }, "benefits": [ "Korrelation und Deduplizierung reduzieren die Alarmmüdigkeit und das Benachrichtigungsvolumen für das On-Call-Personal drastisch.", "Die Automatisierung sicherer, primär lesender Diagnosen verkürzt die mittlere Zeit bis zur Behebung bei gut verstandenen Vorfällen.", "Menschliche Freigabestufen sichern destruktive Aktionen ab, während sie gleichzeitig die Behebung von Risiken mit geringem Potenzial beschleunigen.", "Ein vollständiger Audit-Trail verbessert Postmortems, Compliance und die kontinuierliche Verbesserung von Runbooks." ], "risks": [ "Ein zu großes Vertrauen in Konfidenzwerte kann dazu führen, dass eine falsche Diagnose eine ungeeignete Fehlerbehebung auslöst.", "Eine Automatisierung über geprüfte Runbooks hinaus birgt das Risiko, dass neuartige, ungetestete Aktionen zu größeren Ausfällen führen.", "Eine schlecht abgestimmte Korrelation kann entweder unzusammenhängende Vorfälle zusammenführen oder doppelte Alarme nicht komprimieren.", "Müdigkeit durch Freigabestufen kann dazu führen, dass Ingenieure Anfragen ohne echte Prüfung einfach durchwinken." ], "failureModes": [ "Alarmstürme überfordern die Korrelation und führen entweder zu einem einzigen riesigen Vorfall oder zu einer Flut von Fragmenten.", "Ein fehlerhaftes Runbook führt eine schädliche Aktion aus, die der Evaluator nicht erkennt und nicht rückgängig macht.", "Der Agent eskaliert alles und erzeugt so genau die Alarmmüdigkeit neu, die er eigentlich beseitigen sollte.", "Veraltete Topologie- oder Kontextdaten führen die Diagnose zur falschen Ursache." ], "lessons": [ "Setzen Sie standardmäßig auf primär lesende Automatisierung und fordern Sie für jeden Schreibvorgang oder jede destruktive Aktion eine menschliche Freigabe.", "Führen Sie niemals automatische Fehlerbehebungen über geprüfte, versionierte Runbooks mit getesteten, sicheren Rollback-Pfaden hinaus durch.", "Messen Sie MTTR und die Rate fehlerhafter Aktionen ehrlich, anstatt das Automatisierungsvolumen zu feiern.", "Investieren Sie frühzeitig in die Korrelationsqualität; verrauschte Vorfälle beeinträchtigen sowohl die Diagnose als auch das menschliche Vertrauen." ], "kpis": [ { "metric": "Mittlere Zeit bis zur Behebung (MTTR)", "note": "Separat für durch Runbooks abgedeckte versus eskalierte Vorfälle erfassen; ein gutes Ergebnis zeigt sich in einem stetigen Rückgang bei abgedeckten Fällen ohne Verschlechterungen an anderer Stelle." }, { "metric": "Rate fehlerhafter Aktionen", "note": "Anteil automatisierter Fehlerbehebungen, die falsch oder schädlich waren; ein gutes Ergebnis liegt nahe Null, gestützt durch eine strenge Freigabepflicht für Schreibvorgänge." }, { "metric": "Alarm-zu-Vorfall-Komprimierung", "note": "Verhältnis von Rohalarmen zu korrelierten Vorfällen; ein gutes Ergebnis bedeutet weitaus weniger Benachrichtigungen, ohne echte, eigenständige Probleme zu verbergen." }, { "metric": "Eskalationspräzision", "note": "Anteil der Eskalationen, die tatsächlich einen Menschen erforderten; ein gutes Ergebnis vermeidet sowohl Müdigkeit durch Übereskalation als auch das Übersehen riskanter Fälle." }, { "metric": "Rollback-Erfolgsquote", "note": "Anteil fehlgeschlagener Fehlerbehebungen, die sauber in einen sicheren Zustand zurückgesetzt wurden; ein gutes Ergebnis ist konsistent hoch ohne verbleibende Nebenwirkungen." } ], "scaling": [ "Partitionieren Sie Korrelation und Routing nach Service-Domäne oder Region, sodass das Vorfallsvolumen horizontal skaliert.", "Halten Sie Runbooks versioniert und unabhängig testbar, damit neue Automatisierungen sicher hinzugefügt werden können.", "Nutzen Sie Rate-Limiting und Backpressure bei der Ingestion, um Alarmstürme zu überstehen, ohne die Audit-Genauigkeit zu beeinträchtigen.", "Erweitern Sie die Automatisierungsabdeckung schrittweise, indem Sie Runbooks mit wachsendem Vertrauen von reinen Vorschlägen zu einer freigabepflichtigen Ausführung hochstufen." ], "examples": [ "Korrelieren einer durch ein Deployment ausgelösten Fehlerspitze zu einem einzigen Vorfall und Empfehlen eines freigabepflichtigen Rollbacks des neuesten Release.", "Automatisches Ausführen von schreibgeschützten Festplatten-, Speicher- und Verbindungsdiagnosen und anschließendes Anfordern der Freigabe zum Neustart eines ausgelasteten Dienstes.", "Direktes Eskalieren einer neuartigen Netzwerkanomalie mit geringer Konfidenz an das On-Call-Team mit angereichertem Kontext, anstatt zu raten." ], "faqs": [ { "q": "Warum lassen wir den Agenten nicht alles automatisch beheben?", "a": "Weil destruktive oder neuartige Aktionen weitreichendere Ausfälle verursachen können. Das Pattern automatisiert sichere, primär lesende Diagnosen und sichert jeden Schreibvorgang durch eine menschliche Freigabe und ein geprüftes Runbook ab." }, { "q": "Wie reduziert es Alert Fatigue?", "a": "Eine Correlation Engine dedupliziert und gruppiert zusammenhängende Signale zu einem einzigen Incident, sodass ein zugrunde liegender Fehler nur eine Benachrichtigung (Page) anstelle von Dutzenden redundanter Alarme auslöst." }, { "q": "Was passiert, wenn eine Remediation fehlschlägt?", "a": "Ein Evaluator vergleicht die Ergebnisse mit den erwarteten Health-Signalen und löst einen sicheren, getesteten Rollback aus, während die gesamte Timeline im Audit-Trail für die Post-Mortem-Analyse erfasst wird." } ] }, "ja": { "name": "オペレーションセンター", "summary": "オペレーションセンターは、監視シグナルやアラートを監視し、それらを関連付けてトリアージし、可能性の高い根本原因を診断して、検証済みのランブックによる修復のみを実行する、エージェント型AIOpsシステムです。破壊的なアクションや新しいアクションは、人間の承認を必要とするように制限します。安全な読み取り主体の診断を自動化する一方で、リスクの高い書き込みアクションをオンコールエンジニアにエスカレーションすることで、アラート疲れを軽減し、平均修復時間（MTTR）を短縮します。すべてのアクションは監査可能で、取り消し可能です。成功の尺度は、自動化の量ではなく、MTTR、誤アクション率、エスカレーション精度によって誠実に測定されます。", "keyConcepts": [ "読み取り主体の診断は自動的に実行されます。書き込みや破壊的なアクションには、明示的な人間の承認ゲートが必要です。", "アラートの関連付けにより、ノイズの多い冗長なシグナルを単一のインシデントに集約し、アラート疲れを軽減します。", "修復は、安全なロールバック経路を備えた、検証済みかつバージョン管理されたランブックに限定され、即興のアクションは決して行われません。", "すべての意思決定とアクションは、レビューと学習のために、不変の監査証跡に記録されます。" ], "definition": "オペレーションセンターアーキテクチャは、アラートをトリアージし、根本原因を診断し、承認されたランブック修復のみを実行する一方で、リスクの高いアクションを人間の承認ゲートで制限する、エージェント型AIOpsパターンです。", "architecture": [ "シグナルは、異種混在する監視ツールからのメトリクス、ログ、トレース、アラートを共通のイベントスキーマに統合する、取り込みおよび正規化レイヤーを介して入力されます。関連付けエンジンは、関連するシグナルをサービス、時間枠、依存関係グラフごとにグループ化し、単一の根本的な障害が、数十件の重複する呼び出しではなく、1つのインシデントとして表面化するようにします。", "トリアージおよび診断エージェントは、関連付けられたインシデントを推論し、読み取り専用ツール（ダッシュボード、最近のデプロイ、トポロジ、過去のインシデント）を介して追加のコンテキストを取得し、信頼度の見積もりとともに可能性の高い根本原因を提案します。ルーターは、深刻度、影響範囲、および一致する検証済みランブックが存在するかどうかに基づいて各インシデントを分類し、自動修復、人間の承認、または直接のエスカレーションのいずれかを選択します。", "修復は、保護されたアクションレイヤーを介して実行されます。ここでは、読み取り主体のステップは自動的に実行されますが、書き込み、再起動、スケーリング、またはロールバックは人間の承認ゲートを通過する必要があります。評価機能は、期待されるヘルスシグナルと結果を照合し、安全なロールバックをトリガーできます。オブザーバビリティと不変の監査証跡がすべてのステップをカバーし、時間の経過とともにランブックとルーティングを改善するフィードバックループを提供します。" ], "flow": [ "1. 監視ツールがアラートを発行します。取り込みレイヤーがそれを正規化し、関連付けエンジンが関連するシグナルとマージして1つのインシデントにします。", "2. トリアージエージェントは、最近のデプロイ、トポロジ、ダッシュボード、類似の過去のインシデントなどの読み取り専用コンテキストを使用して、インシデント情報を強化します。", "3. 診断エージェントは、信頼度スコアとともに可能性の高い根本原因を提案し、検証済みのランブックがその症状に一致するかどうかを識別します。", "4. ルーターがパスを決定します。安全な診断を自動実行するか、書き込みアクションに対して人間の承認を要求するか、あるいは新しいケースや信頼度の低いケースをオンコール担当者にエスカレーションします。", "5. 承認された修復がランブックからステップバイステップで実行されます。評価機能がヘルスシグナルを監視し、回復に失敗した場合は自動的にロールバックします。", "6. インシデントが解決されるか人間に引き継がれ、完全なタイムライン、意思決定、およびアクションがレビューのために監査証跡に書き込まれます。" ], "components": [ "シグナル取り込みおよび正規化レイヤー", "アラート関連付けおよび重複排除エンジン", "トリアージおよび根本原因診断エージェント", "深刻度およびランブックルーター", "人間の承認ゲートを備えた保護された修復レイヤー", "安全なロールバックを備えた結果評価機能", "不変の監査証跡とオブザーバビリティ" ], "referenceScenario": { "context": "実例として、2つのリージョンにわたって数十のマイクロサービスを実行している中規模のSaaSプロバイダーは、インシデント発生時に冗長なアラートに圧倒され、対応が遅れています。", "scenario": "データベースの部分的なフェイルオーバー中に、オペレーションセンターは、急増したレイテンシー、エラー率、タイムアウトのアラートを単一のインシデントに関連付け、コネクションプールの枯渇を可能性の高い原因として診断し、読み取り専用のチェックを自動的に実行し、検証済みのランブックからプールワーカーを再利用（リサイクル）する前に人間の承認を要求します。", "technology": "監視およびアラートの統合機能が関連付けエンジンとトリアージエージェントにデータを供給します。インシデント管理システムが状態を追跡し、ランブック自動化が承認されたステップを実行します。人間の承認ゲートとガードレールが書き込みアクションを制限し、オブザーバビリティツールがトレースをキャプチャします。", "load": "参照用の計画数値のみ：1日あたり約4,000件の未加工アラートが数百件のインシデントに集約され、重大なイベント発生時には数分以内に数百件のシグナルがピークバーストとして発生します。", "results": "保証値ではなく、測定すべき参照目標：関連付けによる重複呼び出しの削減、ランブック対象インシデントのMTTR短縮、およびすべての書き込みをゲート制限することによる誤アクション率のほぼゼロ維持を目指します。信頼する前に、すべての数値を独自のベースラインに対して検証してください。" }, "benefits": [ "関連付けと重複排除により、オンコールスタッフのアラート疲れと呼び出し量が大幅に削減されます。", "安全な読み取り主体の診断を自動化することで、十分に理解されているインシデントの平均修復時間が短縮されます。", "人間の承認ゲートにより、低リスクの修復を迅速化しつつ、破壊的なアクションの安全性を維持します。", "完全な監査証跡により、ポストモーテム（事後分析）、コンプライアンス、および継続的なランブックの改善が向上します。" ], "risks": [ "信頼度スコアを過信すると、誤った診断によって不適切な修復が実行される可能性があります。", "検証済みのランブックを超えて自動化すると、テストされていない新しいアクションによって、より広範囲の障害が発生するリスクがあります。", "関連付けの調整が不十分だと、無関係なインシデントがマージされたり、重複の集約に失敗したりする可能性があります。", "承認ゲート疲れにより、エンジニアが実際のレビューを行わずに、要求を形骸的に承認（ラバースタンプ）してしまう可能性があります。" ], "failureModes": [ "アラートストームが関連付け処理を圧倒し、1つの巨大なインシデントまたは大量の断片化されたインシデントが発生します。", "欠陥のあるランブックが有害なアクションを実行し、評価機能がそれを検出してロールバックすることに失敗します。", "エージェントがすべてをエスカレーションしてしまい、解消するはずだったアラート疲れを再発させます。", "古いトポロジやコンテキストデータにより、診断が誤った根本原因に導かれます。" ], "lessons": [ "デフォルトで読み取り主体の自動化を行い、すべての書き込みまたは破壊的なアクションには人間の承認を必須とします。", "テスト済みの安全なロールバック経路を備えた、検証済みかつバージョン管理されたランブックの範囲を超えて自動修復を行わないでください。", "自動化の量を誇るのではなく、MTTRと誤アクション率を誠実に測定してください。", "関連付けの品質に早期に投資してください。ノイズの多いインシデントは、診断の精度と人間の信頼の両方を損ないます。" ], "kpis": [ { "metric": "平均修復時間（MTTR）", "note": "ランブック対象のインシデントとエスカレーションされたインシデントを分けて追跡します。良好な状態とは、他での退行（デグレード）を伴わずに、対象ケースの数値が着実に低下している状態です。" }, { "metric": "誤アクション率", "note": "誤っていた、または有害であった自動修復の割合。良好な状態とは、厳格な書き込みアクションのゲート制限によって維持される、ほぼゼロに近い数値です。" }, { "metric": "アラートからインシデントへの圧縮率", "note": "未加工アラートに対する関連付けられたインシデントの比率。良好な状態とは、実際に発生している個別の問題を隠すことなく、呼び出しが大幅に減少している状態です。" }, { "metric": "エスカレーション精度", "note": "実際に人間を必要としたエスカレーションの割合。良好な状態とは、過剰なエスカレーションによる疲弊と、リスクの高いケースの見落としの両方を回避できている状態です。" }, { "metric": "ロールバック成功率", "note": "失敗した修復のうち、安全な状態にクリーンにロールバックされた割合。良好な状態とは、後を引く副作用がなく、一貫して高い数値を維持している状態です。" } ], "scaling": [ "インシデント量が水平方向にスケールするように、サービスドメインまたはリージョンごとに関連付けとルーティングを分割します。", "新しい自動化を安全に追加できるように、ランブックのバージョンを管理し、個別にテスト可能な状態を維持します。", "監査の忠実性を失うことなくアラートストームを乗り切るために、取り込みのレート制限とバックプレッシャーを適用します。", "信頼度が高まるにつれて、ランブックを「提案のみ」から「ゲート付き実行」へと昇格させ、自動化の適用範囲を段階的に拡大します。" ], "examples": [ "デプロイによってトリガーされたエラーの急増を1つのインシデントに関連付け、最新リリースのゲート付きロールバックを推奨する。", "読み取り専用のディスク、メモリ、接続の診断を自動実行し、飽和状態のサービスを再利用（リサイクル）するための承認を要求する。", "推測に頼るのではなく、情報を強化したコンテキストとともに、新しい信頼度の低いネットワーク異常をオンコール担当者に直接エスカレーションする。" ], "faqs": [ { "q": "なぜエージェントにすべてを自動的に修正させないのですか？", "a": "破壊的または斬新なアクションは、より広範な障害を引き起こす可能性があるためです。このパターンは、安全で読み取り主体の診断を自動化し、すべての書き込みを人間の承認と検証済みのランブックによって制限します。" }, { "q": "アラート疲れをどのように軽減するのですか？", "a": "相関エンジンが関連するシグナルを重複排除して単一のインシデントにグループ化するため、1つの根本的な障害に対して、数十の冗長なアラートではなく、1つのページ（呼び出し）が生成されます。" }, { "q": "修復が失敗した場合はどうなりますか？", "a": "評価器が結果を期待されるヘルスシグナルと比較し、テスト済みの安全なロールバックをトリガーします。同時に、事後分析（ポストモーテム）レビューのために、全タイムラインが監査証跡に記録されます。" } ] }, "zh": { "name": "运维中心", "summary": "运维中心是一个智能体化（agentic）的 AIOps 系统，它监控监控信号和告警，对其进行关联和分诊，诊断可能的根本原因，并仅执行经过审核的运行手册（runbook）修复程序——将破坏性或新颖的操作置于人工审批之后。它通过自动执行安全的、以只读为主的诊断，同时将高风险的写入操作升级给值班工程师，从而减轻告警疲劳并缩短平均恢复时间（MTTR）。每项操作都经过审计且可逆。成功的衡量标准是诚实地评估 MTTR、错误操作率和升级精准度，而不是自动化执行的数量。", "keyConcepts": [ "以只读为主的诊断自动运行；写入或破坏性操作需要明确的人工审批关卡。", "告警关联将嘈杂、冗余的信号折叠为单个事件，以减轻疲劳。", "修复操作仅限于经过审核、有版本控制且具备安全回滚机制的运行手册（runbook）——绝不采取即兴操作。", "每一个决策和操作都会记录在不可篡改的审计追踪中，以便进行复盘和学习。" ], "definition": "运维中心架构是一种智能体化（agentic）的 AIOps 模式，它对告警进行分诊、诊断根本原因，并仅运行经批准的运行手册（runbook）修复程序，同时将高风险操作置于人工审批之后。", "architecture": [ "信号通过摄入和归一化层进入，该层将来自异构监控工具的指标、日志、追踪和告警统一为通用的事件模式（schema）。关联引擎按服务、时间窗口和依赖关系图对相关信号进行分组，从而使单个底层故障表现为单个事件，而不是数十个重复的呼叫（pages）。", "分诊与诊断智能体对关联的事件进行推理，通过只读工具（仪表板、近期部署、拓扑、历史事件）拉取额外的上下文，并提出可能的根本原因及置信度评估。路由器根据严重程度、爆炸半径以及是否存在匹配且经审核的运行手册（runbook）对每个事件进行分类，然后在自动修复、人工审批或直接升级之间做出选择。", "修复通过受保护的操作层执行，其中以只读为主的步骤自动运行，但任何写入、重启、扩缩容或回滚操作都必须通过人工审批关卡。评估器根据预期的健康信号检查结果，并可触发安全回滚。可观测性和不可篡改的审计追踪贯穿每一步，从而形成反馈闭环，随着时间的推移不断改进运行手册（runbook）和路由机制。" ], "flow": [ "1. 监控工具触发告警；摄入层对其进行归一化，关联引擎将其与相关信号合并为单个事件。", "2. 分诊智能体使用只读上下文（近期部署、拓扑、仪表板和类似的过去事件）来丰富事件信息。", "3. 诊断智能体提出可能的根本原因及置信度评分，并确定是否有经审核的运行手册（runbook）与该症状匹配。", "4. 路由器决定路径：自动运行安全诊断、针对写入操作请求人工审批，或者将新颖或低置信度的案例升级给值班人员。", "5. 经批准的修复程序按照运行手册（runbook）逐步运行；评估器监视健康信号，如果恢复失败则自动回滚。", "6. 事件得到解决或移交给人工处理，完整的事件时间线、决策和操作将被写入审计追踪以供复盘。" ], "components": [ "信号摄入与归一化层", "告警关联与去重引擎", "分诊与根本原因诊断智能体", "严重程度与运行手册（runbook）路由器", "带有人工审批关卡的受保护修复层", "带有安全回滚机制的结果评估器", "不可篡改的审计追踪与可观测性" ], "referenceScenario": { "context": "一个典型的中型 SaaS 服务商在两个区域运行着数十个微服务，在发生事件时被冗余的告警所淹没，导致响应变慢。", "scenario": "在部分数据库故障转移期间，运维中心将突发的延迟、错误率和超时告警关联为单个事件，诊断出连接池耗尽是可能的原因，自动运行只读检查，并在根据经审核的运行手册（runbook）回收连接池工作线程之前请求人工审批。", "technology": "监控和告警集成向关联引擎和分诊智能体提供数据；事件管理系统跟踪状态；运行手册（runbook）自动化执行经批准的步骤；人工审批关卡和护栏限制写入操作；可观测性工具捕获追踪。", "load": "仅供参考的规划数据：每天大约 4,000 个原始告警折叠为几百个事件，在重大事件期间，几分钟内会出现数百个信号的峰值突发。", "results": "仅供衡量的参考目标，而非保证：旨在通过关联减少重复呼叫，缩短运行手册（runbook）覆盖事件的 MTTR，并通过限制所有写入操作将错误操作率保持在接近零的水平。在依赖任何数据之前，请对照您自己的基线进行验证。" }, "benefits": [ "关联和去重可大幅减轻值班人员的告警疲劳并减少呼叫量。", "自动执行安全的、以只读为主的诊断可缩短易于理解的事件的平均恢复时间。", "人工审批关卡可确保破坏性操作的安全，同时仍能加速低风险的修复。", "完整的审计追踪可改进事后复盘、合规性以及运行手册（runbook）的持续改进。" ], "risks": [ "过度信任置信度评分可能会导致错误的诊断引发不恰当的修复。", "超出经审核的运行手册（runbook）范围进行自动化，可能会因新颖且未经测试的操作而导致更大范围的停机。", "未经良好调优的关联可能会合并无关的事件，或者无法折叠重复的事件。", "审批关卡疲劳可能会促使工程师在没有进行真正审查的情况下对请求进行“橡皮图章”式的盲目批准。" ], "failureModes": [ "告警风暴压垮关联引擎，导致产生一个巨大的事件或洪水般的碎片事件。", "存在缺陷的运行手册（runbook）执行了有害操作，而评估器未能检测到并进行回滚。", "智能体将所有事件升级，重新制造了原本旨在消除的告警疲劳。", "过期的拓扑或上下文数据导致诊断走向错误的根本原因。" ], "lessons": [ "默认采用以只读为主的自动化，并对每次写入或破坏性操作要求人工审批。", "绝不在经审核、有版本控制且具备经测试的安全回滚路径的运行手册（runbook）之外进行自动修复。", "诚实地衡量 MTTR 和错误操作率，而不是盲目庆祝自动化执行的数量。", "尽早投入资金提高关联质量；嘈杂的事件既会破坏诊断，也会损害人工信任。" ], "kpis": [ { "metric": "平均恢复时间（MTTR）", "note": "分别跟踪运行手册（runbook）覆盖的事件与升级的事件；表现良好的特征是覆盖案例的指标稳步下降，且其他地方没有出现退化。" }, { "metric": "错误操作率", "note": "错误或有害的自动修复所占的比例；表现良好是接近于零，这需要通过严格限制写入操作来维持。" }, { "metric": "告警到事件的压缩率", "note": "原始告警与关联事件的比率；表现良好意味着呼叫次数大幅减少，同时不会隐藏真正独立的问题。" }, { "metric": "升级精准度", "note": "真正需要人工介入的升级比例；表现良好是既能避免过度升级带来的疲劳，又不会遗漏高风险案例。" }, { "metric": "回滚成功率", "note": "失败的修复中干净回滚到安全状态的比例；表现良好是持续保持高水平且无遗留副作用。" } ], "scaling": [ "按服务领域或区域对关联和路由进行分区，以便事件量可以水平扩展。", "保持运行手册（runbook）的版本控制和独立可测试性，以便安全地添加新的自动化。", "对摄入进行限流和背压控制，以便在告警风暴中幸存下来，同时不丢失审计的准确性。", "逐步扩大自动化覆盖范围，随着置信度的提高，将运行手册（runbook）从“仅建议”提升为“受控执行”。" ], "examples": [ "将部署触发的错误激增关联为单个事件，并建议对最新版本进行受控回滚。", "自动运行只读的磁盘、内存和连接诊断，然后请求批准以回收饱和的服务。", "将新颖、低置信度的网络异常直接升级给值班人员，并提供丰富的上下文，而不是凭空猜测。" ], "faqs": [ { "q": "为什么不让智能体自动修复所有问题？", "a": "因为破坏性或新颖的操作可能会导致更大范围的停机。该模式实现了安全的、以只读为主的诊断自动化，并将每次写入操作都置于人工审批和经过审核的运行手册（runbook）的双重把关之下。" }, { "q": "它是如何减少告警疲劳的？", "a": "关联引擎会对相关信号进行去重和分组，并将其归入单个事件中，因此一个底层故障只会产生一次呼叫，而不是数十个冗余告警。" }, { "q": "当修复操作出现问题时会发生什么？", "a": "评估器会将结果与预期的健康信号进行对比，并触发安全且经过测试的回滚，同时完整的时间线会被记录在审计追踪中，以便进行事后复盘分析。" } ] } } }, { "id": "ARCH-006", "slug": "agentic-immune-system", "category": "operations", "updated": "2026-09-10", "version": "1.0", "url": "https://santismm.com/en/architectures/agentic-immune-system", "api": "https://santismm.com/api/architectures/agentic-immune-system", "canonical_url": "https://santismm.com/en/architectures/agentic-immune-system", "api_url": "https://santismm.com/api/architectures/agentic-immune-system", "evidence": { "evidenceLevel": "industry_observation", "confidenceLevel": "medium", "sourceType": [ "industry_observation", "paper" ] }, "technologies": [ "Short-lived workload identity (OIDC / SPIFFE-style)", "Capability-scoped tool broker (MCP or equivalent)", "Sandboxed execution (container or microVM)", "Egress allowlist / forward proxy", "Output encoding at the trust boundary", "Distributed tracing with a run correlation id", "Policy engine for risk-based approval" ], "patterns": [ "least-privilege-tooling", "sandboxed-execution", "egress-allowlist", "output-boundary-encoding", "human-approval-gate", "human-escalation", "recovery-strategy", "correlated-run-trace" ], "knowledge": [ "agentic-threat-model", "mcp-security", "prompt-injection", "guardrails", "ai-cyberdefense", "human-in-the-loop", "ai-observability", "ai-agent" ], "references": [ { "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" }, { "title": "OWASP — Top 10 for Large Language Model Applications", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/" }, { "title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems", "url": "https://atlas.mitre.org/" }, { "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" }, { "title": "Santa María, S. — The agentic enterprise needs an immune system (2026)", "url": "https://articles.santismm.com/the-agentic-enterprise-needs-an-immune-system/" } ], "related": [ "customer-service-agent", "ai-workforce", "operations-center" ], "locales": { "en": { "name": "Agentic Immune System", "summary": "A reference architecture for running enterprise AI agents without concentrating trust in any one of them. Five layers — identity, least privilege, containment, oversight and recovery — assume that some agent will eventually be wrong or subverted, and make that event survivable instead of catastrophic. The unit of defence is the individual run, not the fleet.", "keyConcepts": [ "Assume compromise: the question is not whether an agent will act wrongly but what it can reach when it does.", "Identity per run: every agent execution carries its own short-lived identity, never a shared operator credential.", "Containment over prevention: blast radius is designed, not hoped for — a subverted run affects one task, not the estate.", "Recovery is a design surface: the ability to trace, undo and stop is built in, not improvised during the incident." ], "definition": "The agentic immune system is a layered runtime architecture that lets AI agents take real actions on enterprise systems while bounding what any single run can reach, observe or damage, through per-run identity, task-scoped privilege, execution and egress containment, risk-based human oversight, and traceable recovery.", "architecture": [ "The architecture inverts the usual question. Instead of asking how to stop an agent from making a mistake — which no guardrail achieves reliably against a system that reasons — it asks what the agent can reach at the moment it makes one. Every layer is a bound on reach, and the layers are independent so that one failing does not open the rest.", "Identity is the foundation. Each run is issued a short-lived credential bound to the task, the requesting principal and the tools it declared it needs. Agents do not share a service account: when something goes wrong, the trace names a run, not a fleet, and revocation costs one token rather than a rotation across the estate.", "Privilege is scoped to the task and expires with it. The tool broker grants the narrow set of capabilities a run declared up front — read this ticket, write this record — and refuses anything outside it, so a prompt injection that persuades the model to attempt more finds nothing to call.", "Containment assumes the first two layers can be defeated. Execution happens in a sandbox with no ambient credentials; outbound network access goes through an allowlist so exfiltration has nowhere to send; and anything the agent produces is encoded at the boundary so its output cannot become the next system's instruction.", "Oversight is where a human carries accountability, placed by risk rather than by default: irreversible or regulated actions pause for approval, and low-confidence outcomes escalate with the full run context attached. Gating everything defeats the automation and trains reviewers to click through.", "Recovery closes the loop. Every run is traced under a single correlation id across models, tools and retries; actions are designed with a compensating counterpart where the underlying system allows it; and a kill switch stops a class of runs without taking down the platform." ], "flow": [ "1. Request: a task arrives with its requesting principal and a declared set of tools and data scopes.", "2. Issue: the broker mints a short-lived, run-scoped identity bound to that declaration.", "3. Admit: the run starts in a sandbox with no ambient credentials and an egress allowlist.", "4. Act: every tool call is authorised against the run's scope; anything outside it is refused and recorded.", "5. Gate: irreversible or regulated actions pause for human approval with the run context attached.", "6. Emit: outputs are encoded at the boundary so they cannot be executed as instructions downstream.", "7. Close: the identity expires, the trace is sealed under its correlation id, and compensating actions stay available." ], "components": [ "Run identity broker (short-lived, task-bound credentials)", "Tool broker with declared capability scopes", "Sandboxed execution environment", "Egress allowlist and data-loss controls", "Output boundary encoder", "Risk-based human approval gate", "Correlated run trace and audit log", "Compensating actions and kill switch" ], "referenceScenario": { "context": "An illustrative enterprise running dozens of agents across ticketing, finance and internal knowledge, where each agent can both read and write to systems of record.", "scenario": "A retrieval step ingests a document containing an injected instruction telling the agent to export customer records. The model complies, but the export tool is outside the run's declared scope and is refused; the attempt is recorded, the run is stopped by the anomaly rule, and the correlation id gives the responder the full chain in one query.", "technology": "Per-run credential broker, capability-scoped tool broker, sandboxed execution, egress allowlist, boundary encoding, risk-based approval gate, correlated tracing.", "load": "Continuous background automation with bursts around business processes; the rare, high-impact action is a small fraction of calls and the one that carries the risk.", "results": "Reference target, not a measured outcome: a subverted run is bounded to its declared scope, every refusal is attributable to a run, and any action taken can be traced and — where the underlying system permits — compensated." }, "benefits": [ "A wrong or subverted agent costs one task, not the estate.", "Incidents are attributable to a run rather than to a shared account, so response is targeted and revocation is cheap.", "Prompt injection loses most of its value: persuading the model does not grant it capability it never held.", "Oversight effort concentrates on the actions that are actually irreversible, keeping approval meaningful." ], "risks": [ "Scope declarations drift from what agents actually need, so teams widen them until least privilege is nominal.", "Gating too much trains reviewers to approve without reading, which is worse than not gating at all.", "Sandboxing and brokering add latency and operational surface that small deployments may not justify.", "Compensating actions are impossible for some external effects — a sent email or a paid invoice does not roll back." ], "failureModes": [ "A shared service credential survives somewhere in the stack and silently defeats per-run identity.", "The egress allowlist is bypassed through an approved destination that itself forwards data.", "Traces break across a retry or a model switch, so the incident chain cannot be reconstructed.", "The approval queue backs up and the gate is disabled 'temporarily' to clear a backlog.", "Tool output is treated as trusted input by the next step, turning containment into a single boundary that leaks." ], "lessons": [ "Design the blast radius before the capability: what an agent may reach is a harder question than what it may do, and answering it first makes the rest tractable.", "Per-run identity is the load-bearing layer; without it every other control is enforced against a subject you cannot name.", "A gate that fires on everything is a gate that fires on nothing — reserve human approval for the irreversible.", "Assume the model will be persuaded and design so that persuasion is not authorisation.", "Recovery has to be built while the system is calm; nobody designs a compensating action during an incident." ], "kpis": [ { "metric": "Share of runs with a unique, short-lived identity", "note": "The load-bearing control. Anything short of 100% means some path still uses a shared credential." }, { "metric": "Out-of-scope tool attempts, refused", "note": "Counted per run. A rising number is a signal about the environment, not necessarily a failure of the design." }, { "metric": "Blast radius per run", "note": "Number of systems and records a single run could reach if fully subverted. The number the architecture exists to shrink." }, { "metric": "Gated action rate and approval latency", "note": "Both matter: too high a rate defeats automation, too high a latency makes teams disable the gate." }, { "metric": "Trace completeness", "note": "Share of runs reconstructable end to end under one correlation id, including retries and model switches." }, { "metric": "Time to revoke", "note": "From detection to a run's capability being gone. Short-lived credentials should make this close to expiry, not to a rotation." } ], "scaling": [ "The identity and tool brokers are on the hot path of every call, so they set the ceiling; they are stateless and scale horizontally, but their latency is paid on every tool use.", "Sandbox start-up dominates cost for short runs; pooling warm sandboxes trades isolation depth for latency and should be an explicit decision.", "Human approval does not scale linearly and is the real constraint — the gated set must stay small as the fleet grows or the queue becomes the outage.", "Trace storage grows with runs times tool calls; sampling is safe for observability but not for audit, so the two retention policies should be separate." ], "examples": [ "An injected instruction in a retrieved document asks for a data export; the tool is outside the run's scope and the call is refused and recorded.", "A finance agent drafts a payment and a human approves it before execution, with the run trace attached to the approval.", "A misbehaving agent class is stopped by kill switch while the rest of the fleet keeps running.", "An incident is reconstructed from a single correlation id spanning three models, nine tool calls and two retries." ], "faqs": [ { "q": "Why an immune system rather than a firewall?", "a": "A firewall assumes a boundary between inside and outside. An enterprise running agents has no such boundary: the agent is already inside, acting with real credentials. An immune system assumes intrusion is normal and invests in recognition, containment and repair rather than in a perimeter." }, { "q": "Isn't this just least privilege with extra steps?", "a": "Least privilege is one of the five layers and the most familiar. The architecture's claim is that it is not sufficient alone: without per-run identity you cannot scope privilege to a subject, and without containment and recovery a correctly-scoped run that still goes wrong has no bound and no undo." }, { "q": "Does this stop prompt injection?", "a": "No, and treating any control as stopping it is the mistake. It makes injection cheap to survive: persuading the model to attempt an action is not the same as the action being authorised, and the refused attempt is itself a signal." }, { "q": "What is the minimum viable version?", "a": "Per-run identity and task-scoped tool access. Those two give you attribution and a bound. Containment, gating and compensating actions matter more as the actions get more irreversible." }, { "q": "How does this relate to the governance frameworks?", "a": "It is the runtime expression of what they require. NIST AI RMF and ISO 42001 ask for accountability and traceability; OWASP LLM Top 10 and MITRE ATLAS describe the attacks. This architecture is where those obligations become identities, scopes, sandboxes and traces." } ] }, "es": { "name": "Sistema inmunitario agéntico", "summary": "Arquitectura de referencia para operar agentes de IA en la empresa sin concentrar la confianza en ninguno de ellos. Cinco capas —identidad, mínimo privilegio, contención, supervisión y recuperación— dan por supuesto que algún agente acabará equivocándose o siendo subvertido, y hacen que ese día sea sobrevivible en vez de catastrófico. La unidad de defensa es la ejecución concreta, no la flota.", "keyConcepts": [ "Dar por hecho el compromiso: la pregunta no es si un agente actuará mal, sino hasta dónde llega cuando lo haga.", "Identidad por ejecución: cada ejecución lleva su propia credencial efímera, nunca una cuenta de operador compartida.", "Contención antes que prevención: el radio de daño se diseña, no se espera — una ejecución subvertida afecta a una tarea, no al parque.", "La recuperación es una superficie de diseño: trazar, deshacer y parar se construyen antes, no se improvisan durante el incidente." ], "definition": "El sistema inmunitario agéntico es una arquitectura de ejecución por capas que permite a los agentes de IA actuar de verdad sobre los sistemas de la empresa acotando lo que una sola ejecución puede alcanzar, observar o dañar, mediante identidad por ejecución, privilegio limitado a la tarea, contención de ejecución y de salida, supervisión humana por riesgo y recuperación trazable.", "architecture": [ "La arquitectura invierte la pregunta habitual. En vez de preguntar cómo impedir que un agente se equivoque —cosa que ninguna barrera consigue de forma fiable frente a un sistema que razona— pregunta hasta dónde llega el agente en el momento en que se equivoca. Cada capa es un límite de alcance, y las capas son independientes para que el fallo de una no abra las demás.", "La identidad es el cimiento. Cada ejecución recibe una credencial efímera ligada a la tarea, a quien la pide y a las herramientas que declaró necesitar. Los agentes no comparten cuenta de servicio: cuando algo sale mal, la traza nombra una ejecución y no una flota, y revocar cuesta un token en vez de una rotación en todo el parque.", "El privilegio se limita a la tarea y caduca con ella. El intermediario de herramientas concede el conjunto estrecho de capacidades que la ejecución declaró de antemano —leer este ticket, escribir este registro— y rechaza cualquier otra, de modo que una inyección de prompt que convenza al modelo de intentar más no encuentra nada que llamar.", "La contención da por supuesto que las dos capas anteriores pueden caer. La ejecución ocurre en un entorno aislado sin credenciales ambientales; la salida a red pasa por una lista de destinos permitidos, así que la exfiltración no tiene adónde enviar; y lo que el agente produce se codifica en la frontera para que su salida no se convierta en la instrucción del siguiente sistema.", "La supervisión es donde una persona asume la responsabilidad, colocada por riesgo y no por defecto: las acciones irreversibles o reguladas se detienen a esperar aprobación, y los resultados de baja confianza escalan con todo el contexto de la ejecución. Poner puerta a todo derrota la automatización y enseña a los revisores a aprobar sin leer.", "La recuperación cierra el círculo. Cada ejecución se traza bajo un único identificador de correlación a través de modelos, herramientas y reintentos; las acciones se diseñan con su contrapartida compensatoria cuando el sistema de destino lo permite; y un interruptor de parada detiene una clase de ejecuciones sin tumbar la plataforma." ], "flow": [ "1. Petición: llega una tarea con quien la solicita y un conjunto declarado de herramientas y ámbitos de datos.", "2. Emisión: el intermediario acuña una identidad efímera, limitada a la ejecución y ligada a esa declaración.", "3. Admisión: la ejecución arranca en un entorno aislado, sin credenciales ambientales y con lista de salida permitida.", "4. Acción: cada llamada a herramienta se autoriza contra el ámbito de la ejecución; lo que queda fuera se rechaza y se registra.", "5. Puerta: las acciones irreversibles o reguladas se detienen a esperar aprobación humana con el contexto adjunto.", "6. Emisión de salida: lo producido se codifica en la frontera para que aguas abajo no se ejecute como instrucción.", "7. Cierre: la identidad caduca, la traza se sella bajo su identificador de correlación y las acciones compensatorias siguen disponibles." ], "components": [ "Emisor de identidad por ejecución (credenciales efímeras ligadas a la tarea)", "Intermediario de herramientas con ámbitos de capacidad declarados", "Entorno de ejecución aislado", "Lista de salida permitida y controles de fuga de datos", "Codificador de frontera de salida", "Puerta de aprobación humana por riesgo", "Traza de ejecución correlacionada y registro de auditoría", "Acciones compensatorias e interruptor de parada" ], "referenceScenario": { "context": "Una empresa ilustrativa que opera decenas de agentes en ticketing, finanzas y conocimiento interno, donde cada agente puede leer y escribir en sistemas de registro.", "scenario": "Un paso de recuperación ingiere un documento con una instrucción inyectada que pide al agente exportar registros de clientes. El modelo obedece, pero la herramienta de exportación queda fuera del ámbito declarado de la ejecución y se rechaza; el intento queda registrado, la regla de anomalía detiene la ejecución y el identificador de correlación da a quien responde la cadena completa en una sola consulta.", "technology": "Emisor de credenciales por ejecución, intermediario de herramientas con ámbitos, ejecución aislada, lista de salida permitida, codificación de frontera, puerta de aprobación por riesgo y trazado correlacionado.", "load": "Automatización continua de fondo con picos alrededor de los procesos de negocio; la acción rara y de alto impacto es una fracción pequeña de las llamadas y es la que carga el riesgo.", "results": "Objetivo de referencia, no una medición: una ejecución subvertida queda acotada a su ámbito declarado, cada rechazo es atribuible a una ejecución, y toda acción ejecutada se puede trazar y —cuando el sistema de destino lo permite— compensar." }, "benefits": [ "Un agente equivocado o subvertido cuesta una tarea, no el parque entero.", "Los incidentes son atribuibles a una ejecución y no a una cuenta compartida, así que la respuesta es dirigida y revocar sale barato.", "La inyección de prompt pierde casi todo su valor: convencer al modelo no le concede una capacidad que nunca tuvo.", "El esfuerzo de supervisión se concentra en las acciones realmente irreversibles, y así la aprobación sigue significando algo." ], "risks": [ "Los ámbitos declarados se separan de lo que los agentes necesitan de verdad y los equipos los ensanchan hasta que el mínimo privilegio es nominal.", "Poner puerta a demasiadas cosas enseña a los revisores a aprobar sin leer, que es peor que no poner puerta.", "El aislamiento y los intermediarios añaden latencia y superficie operativa que un despliegue pequeño quizá no justifique.", "Hay efectos externos que no admiten compensación: un correo enviado o una factura pagada no se deshacen." ], "failureModes": [ "Una credencial de servicio compartida sobrevive en algún punto de la pila y derrota en silencio la identidad por ejecución.", "La lista de salida se sortea a través de un destino permitido que a su vez reenvía los datos.", "Las trazas se rompen en un reintento o en un cambio de modelo, y la cadena del incidente ya no se puede reconstruir.", "La cola de aprobación se atasca y la puerta se desactiva «temporalmente» para vaciarla.", "La salida de una herramienta se trata como entrada de confianza en el paso siguiente, y la contención pasa a ser una sola frontera con fugas." ], "lessons": [ "Diseña el radio de daño antes que la capacidad: hasta dónde puede llegar un agente es una pregunta más difícil que qué puede hacer, y contestarla primero hace tratable el resto.", "La identidad por ejecución es la capa que sostiene el peso; sin ella, cualquier otro control se aplica contra un sujeto que no sabes nombrar.", "Una puerta que salta con todo es una puerta que no salta con nada: reserva la aprobación humana para lo irreversible.", "Da por hecho que al modelo lo convencerán, y diseña para que convencer no sea autorizar.", "La recuperación hay que construirla con el sistema en calma; nadie diseña una acción compensatoria durante un incidente." ], "kpis": [ { "metric": "Ejecuciones con identidad propia y efímera", "note": "El control que sostiene el peso. Cualquier cifra por debajo del 100 % significa que algún camino sigue usando una credencial compartida." }, { "metric": "Intentos de herramienta fuera de ámbito, rechazados", "note": "Contados por ejecución. Que suban dice algo del entorno, no necesariamente que el diseño falle." }, { "metric": "Radio de daño por ejecución", "note": "Cuántos sistemas y registros podría alcanzar una sola ejecución completamente subvertida. Es el número que la arquitectura existe para encoger." }, { "metric": "Tasa de acciones con puerta y latencia de aprobación", "note": "Importan las dos: una tasa alta derrota la automatización y una latencia alta hace que los equipos desactiven la puerta." }, { "metric": "Completitud de la traza", "note": "Proporción de ejecuciones reconstruibles de principio a fin bajo un identificador de correlación, reintentos y cambios de modelo incluidos." }, { "metric": "Tiempo hasta revocar", "note": "Desde la detección hasta que la capacidad de una ejecución ya no existe. Con credenciales efímeras debería parecerse a su caducidad, no a una rotación." } ], "scaling": [ "Los intermediarios de identidad y de herramientas están en el camino caliente de cada llamada, así que marcan el techo; son sin estado y escalan en horizontal, pero su latencia se paga en cada uso de herramienta.", "El arranque del entorno aislado domina el coste de las ejecuciones cortas; mantener entornos calientes en pool cambia profundidad de aislamiento por latencia y debe ser una decisión explícita.", "La aprobación humana no escala de forma lineal y es la restricción real: el conjunto con puerta tiene que seguir siendo pequeño según crece la flota, o la cola se convierte en la caída.", "El almacenamiento de trazas crece con ejecuciones por llamadas a herramienta; muestrear vale para observabilidad pero no para auditoría, así que las dos políticas de retención deben ir separadas." ], "examples": [ "Una instrucción inyectada en un documento recuperado pide una exportación de datos; la herramienta queda fuera del ámbito de la ejecución y la llamada se rechaza y se registra.", "Un agente de finanzas prepara un pago y una persona lo aprueba antes de ejecutarlo, con la traza de la ejecución adjunta a la aprobación.", "Una clase de agente que se comporta mal se detiene con el interruptor de parada mientras el resto de la flota sigue funcionando.", "Un incidente se reconstruye desde un único identificador de correlación que abarca tres modelos, nueve llamadas a herramienta y dos reintentos." ], "faqs": [ { "q": "¿Por qué un sistema inmunitario y no un cortafuegos?", "a": "Un cortafuegos supone una frontera entre dentro y fuera. Una empresa que opera agentes no tiene esa frontera: el agente ya está dentro, actuando con credenciales reales. Un sistema inmunitario da por normal la intrusión e invierte en reconocimiento, contención y reparación en vez de en un perímetro." }, { "q": "¿No es mínimo privilegio con pasos de más?", "a": "El mínimo privilegio es una de las cinco capas y la más conocida. Lo que sostiene la arquitectura es que por sí sola no basta: sin identidad por ejecución no puedes limitar el privilegio a un sujeto, y sin contención ni recuperación una ejecución bien acotada que aun así sale mal no tiene ni límite ni marcha atrás." }, { "q": "¿Esto detiene la inyección de prompt?", "a": "No, y tratar cualquier control como si la detuviera es justo el error. Lo que hace es abaratar sobrevivirla: convencer al modelo de intentar una acción no es lo mismo que esa acción esté autorizada, y el intento rechazado es en sí mismo una señal." }, { "q": "¿Cuál es la versión mínima viable?", "a": "Identidad por ejecución y acceso a herramientas limitado a la tarea. Esas dos dan atribución y un límite. La contención, la puerta y las acciones compensatorias pesan más cuanto más irreversibles se vuelven las acciones." }, { "q": "¿Qué relación tiene con los marcos de gobernanza?", "a": "Es su expresión en tiempo de ejecución. NIST AI RMF e ISO 42001 piden responsabilidad y trazabilidad; OWASP LLM Top 10 y MITRE ATLAS describen los ataques. Esta arquitectura es donde esas obligaciones se convierten en identidades, ámbitos, entornos aislados y trazas." } ] }, "pt": { "name": "Sistema imunológico agêntico", "summary": "Arquitetura de referência para operar agentes de IA na empresa sem concentrar a confiança em nenhum deles. Cinco camadas — identidade, privilégio mínimo, contenção, supervisão e recuperação — partem do princípio de que algum agente acabará por errar ou ser subvertido, e tornam esse dia sobrevivível em vez de catastrófico. A unidade de defesa é a execução concreta, não a frota.", "keyConcepts": [ "Assumir o comprometimento: a pergunta não é se um agente vai agir mal, mas até onde ele chega quando o fizer.", "Identidade por execução: cada execução leva a sua própria credencial efêmera, nunca uma conta de operador compartilhada.", "Contenção antes de prevenção: o raio de dano é projetado, não esperado — uma execução subvertida afeta uma tarefa, não o parque.", "A recuperação é uma superfície de projeto: rastrear, desfazer e parar constroem-se antes, não se improvisam durante o incidente." ], "definition": "O sistema imunológico agêntico é uma arquitetura de execução em camadas que permite aos agentes de IA agir de fato sobre os sistemas da empresa, limitando o que uma única execução consegue alcançar, observar ou danificar, através de identidade por execução, privilégio limitado à tarefa, contenção de execução e de saída, supervisão humana por risco e recuperação rastreável.", "architecture": [ "A arquitetura inverte a pergunta habitual. Em vez de perguntar como impedir que um agente erre — algo que nenhuma barreira consegue de forma confiável perante um sistema que raciocina — pergunta até onde o agente chega no momento em que erra. Cada camada é um limite de alcance, e as camadas são independentes para que a falha de uma não abra as restantes.", "A identidade é o alicerce. Cada execução recebe uma credencial efêmera ligada à tarefa, a quem a pediu e às ferramentas que declarou precisar. Os agentes não compartilham conta de serviço: quando algo corre mal, o rastro nomeia uma execução e não uma frota, e revogar custa um token em vez de uma rotação em todo o parque.", "O privilégio limita-se à tarefa e caduca com ela. O intermediário de ferramentas concede o conjunto estreito de capacidades que a execução declarou à partida — ler este ticket, escrever este registro — e recusa tudo o resto, de modo que uma injeção de prompt que convença o modelo a tentar mais não encontra nada para chamar.", "A contenção parte do princípio de que as duas camadas anteriores podem cair. A execução acontece num ambiente isolado sem credenciais ambientais; a saída de rede passa por uma lista de destinos permitidos, pelo que a exfiltração não tem para onde enviar; e o que o agente produz é codificado na fronteira para que a sua saída não se torne a instrução do sistema seguinte.", "A supervisão é onde uma pessoa assume a responsabilidade, colocada por risco e não por padrão: as ações irreversíveis ou reguladas param à espera de aprovação, e os resultados de baixa confiança escalam com todo o contexto da execução. Pôr porta em tudo derrota a automação e ensina os revisores a aprovar sem ler.", "A recuperação fecha o ciclo. Cada execução é rastreada sob um único identificador de correlação através de modelos, ferramentas e novas tentativas; as ações são projetadas com a sua contrapartida compensatória quando o sistema de destino o permite; e um interruptor de paragem detém uma classe de execuções sem derrubar a plataforma." ], "flow": [ "1. Pedido: chega uma tarefa com quem a solicita e um conjunto declarado de ferramentas e âmbitos de dados.", "2. Emissão: o intermediário cunha uma identidade efêmera, limitada à execução e ligada a essa declaração.", "3. Admissão: a execução arranca num ambiente isolado, sem credenciais ambientais e com lista de saída permitida.", "4. Ação: cada chamada a ferramenta é autorizada contra o âmbito da execução; o que fica de fora é recusado e registado.", "5. Porta: as ações irreversíveis ou reguladas param à espera de aprovação humana com o contexto anexado.", "6. Saída: o que é produzido é codificado na fronteira para que a jusante não seja executado como instrução.", "7. Fecho: a identidade caduca, o rastro é selado sob o seu identificador de correlação e as ações compensatórias continuam disponíveis." ], "components": [ "Emissor de identidade por execução (credenciais efêmeras ligadas à tarefa)", "Intermediário de ferramentas com âmbitos de capacidade declarados", "Ambiente de execução isolado", "Lista de saída permitida e controles de fuga de dados", "Codificador de fronteira de saída", "Porta de aprovação humana por risco", "Rastro de execução correlacionado e registro de auditoria", "Ações compensatórias e interruptor de paragem" ], "referenceScenario": { "context": "Uma empresa ilustrativa operando dezenas de agentes em ticketing, finanças e conhecimento interno, onde cada agente pode ler e escrever em sistemas de registro.", "scenario": "Um passo de recuperação ingere um documento com uma instrução injetada que pede ao agente para exportar registros de clientes. O modelo obedece, mas a ferramenta de exportação fica fora do âmbito declarado da execução e é recusada; a tentativa fica registada, a regra de anomalia detém a execução e o identificador de correlação dá a quem responde a cadeia completa numa só consulta.", "technology": "Emissor de credenciais por execução, intermediário de ferramentas com âmbitos, execução isolada, lista de saída permitida, codificação de fronteira, porta de aprovação por risco e rastreio correlacionado.", "load": "Automação contínua de fundo com picos à volta dos processos de negócio; a ação rara e de alto impacto é uma fração pequena das chamadas e é a que carrega o risco.", "results": "Objetivo de referência, não uma medição: uma execução subvertida fica limitada ao seu âmbito declarado, cada recusa é atribuível a uma execução, e toda a ação executada pode ser rastreada e — quando o sistema de destino o permite — compensada." }, "benefits": [ "Um agente errado ou subvertido custa uma tarefa, não o parque inteiro.", "Os incidentes são atribuíveis a uma execução e não a uma conta compartilhada, pelo que a resposta é dirigida e revogar sai barato.", "A injeção de prompt perde quase todo o seu valor: convencer o modelo não lhe concede uma capacidade que nunca teve.", "O esforço de supervisão concentra-se nas ações realmente irreversíveis, e assim a aprovação continua a significar alguma coisa." ], "risks": [ "Os âmbitos declarados afastam-se do que os agentes precisam de fato e as equipas alargam-nos até o privilégio mínimo ser nominal.", "Pôr porta em demasiadas coisas ensina os revisores a aprovar sem ler, o que é pior do que não pôr porta.", "O isolamento e os intermediários acrescentam latência e superfície operacional que uma implantação pequena talvez não justifique.", "Há efeitos externos que não admitem compensação: um email enviado ou uma fatura paga não se desfazem." ], "failureModes": [ "Uma credencial de serviço compartilhada sobrevive nalgum ponto da pilha e derrota em silêncio a identidade por execução.", "A lista de saída é contornada através de um destino permitido que por sua vez reencaminha os dados.", "Os rastros partem-se numa nova tentativa ou numa troca de modelo, e a cadeia do incidente já não pode ser reconstruída.", "A fila de aprovação entope e a porta é desativada “temporariamente” para a esvaziar.", "A saída de uma ferramenta é tratada como entrada de confiança no passo seguinte, e a contenção passa a ser uma só fronteira com fugas." ], "lessons": [ "Projeta o raio de dano antes da capacidade: até onde um agente pode chegar é uma pergunta mais difícil do que o que ele pode fazer, e respondê-la primeiro torna o resto tratável.", "A identidade por execução é a camada que sustenta o peso; sem ela, qualquer outro controle é aplicado contra um sujeito que não sabes nomear.", "Uma porta que dispara com tudo é uma porta que não dispara com nada: reserva a aprovação humana para o irreversível.", "Assume que o modelo vai ser convencido e projeta para que convencer não seja autorizar.", "A recuperação tem de ser construída com o sistema em calma; ninguém projeta uma ação compensatória durante um incidente." ], "kpis": [ { "metric": "Execuções com identidade própria e efêmera", "note": "O controle que sustenta o peso. Qualquer número abaixo dos 100 % significa que algum caminho continua a usar uma credencial compartilhada." }, { "metric": "Tentativas de ferramenta fora de âmbito, recusadas", "note": "Contadas por execução. Subirem diz algo sobre o ambiente, não necessariamente que o desenho falha." }, { "metric": "Raio de dano por execução", "note": "Quantos sistemas e registros uma única execução totalmente subvertida conseguiria alcançar. É o número que a arquitetura existe para encolher." }, { "metric": "Taxa de ações com porta e latência de aprovação", "note": "Importam as duas: uma taxa alta derrota a automação e uma latência alta faz com que as equipas desativem a porta." }, { "metric": "Completude do rastro", "note": "Proporção de execuções reconstruíveis de ponta a ponta sob um identificador de correlação, incluindo novas tentativas e trocas de modelo." }, { "metric": "Tempo até revogar", "note": "Da detecção até a capacidade de uma execução deixar de existir. Com credenciais efêmeras deveria parecer-se com a sua caducidade, não com uma rotação." } ], "scaling": [ "Os intermediários de identidade e de ferramentas estão no caminho quente de cada chamada, pelo que marcam o teto; não têm estado e escalam na horizontal, mas a sua latência paga-se em cada uso de ferramenta.", "O arranque do ambiente isolado domina o custo das execuções curtas; manter ambientes quentes em pool troca profundidade de isolamento por latência e deve ser uma decisão explícita.", "A aprovação humana não escala de forma linear e é a restrição real: o conjunto com porta tem de continuar pequeno à medida que a frota cresce, ou a fila torna-se a paragem.", "O armazenamento de rastros cresce com execuções vezes chamadas a ferramenta; amostrar serve para observabilidade mas não para auditoria, pelo que as duas políticas de retenção devem ir separadas." ], "examples": [ "Uma instrução injetada num documento recuperado pede uma exportação de dados; a ferramenta fica fora do âmbito da execução e a chamada é recusada e registada.", "Um agente de finanças prepara um pagamento e uma pessoa aprova-o antes de o executar, com o rastro da execução anexado à aprovação.", "Uma classe de agente que se comporta mal é detida com o interruptor de paragem enquanto o resto da frota continua funcionando.", "Um incidente é reconstruído a partir de um único identificador de correlação que abrange três modelos, nove chamadas a ferramenta e duas novas tentativas." ], "faqs": [ { "q": "Porquê um sistema imunológico e não uma firewall?", "a": "Uma firewall pressupõe uma fronteira entre dentro e fora. Uma empresa que opera agentes não tem essa fronteira: o agente já está dentro, agindo com credenciais reais. Um sistema imunológico assume a intrusão como normal e investe em reconhecimento, contenção e reparação em vez de num perímetro." }, { "q": "Não é privilégio mínimo com passos a mais?", "a": "O privilégio mínimo é uma das cinco camadas e a mais conhecida. O que a arquitetura sustenta é que por si só não chega: sem identidade por execução não consegues limitar o privilégio a um sujeito, e sem contenção nem recuperação uma execução bem delimitada que ainda assim corre mal não tem limite nem marcha atrás." }, { "q": "Isto detém a injeção de prompt?", "a": "Não, e tratar qualquer controle como se a detivesse é precisamente o erro. O que faz é baratear sobreviver-lhe: convencer o modelo a tentar uma ação não é o mesmo que essa ação estar autorizada, e a tentativa recusada é em si mesma um sinal." }, { "q": "Qual é a versão mínima viável?", "a": "Identidade por execução e acesso a ferramentas limitado à tarefa. Essas duas dão atribuição e um limite. A contenção, a porta e as ações compensatórias pesam mais quanto mais irreversíveis se tornam as ações." }, { "q": "Que relação tem com os quadros de governança?", "a": "É a sua expressão em tempo de execução. O NIST AI RMF e a ISO 42001 pedem responsabilidade e rastreabilidade; o OWASP LLM Top 10 e o MITRE ATLAS descrevem os ataques. Esta arquitetura é onde essas obrigações se transformam em identidades, âmbitos, ambientes isolados e rastros." } ] }, "fr": { "name": "Système immunitaire agentique", "summary": "Architecture de référence pour exploiter des agents d'IA en entreprise sans concentrer la confiance sur aucun d'eux. Cinq couches — identité, moindre privilège, confinement, supervision et récupération — partent du principe qu'un agent finira par se tromper ou être détourné, et rendent ce jour survivable plutôt que catastrophique. L'unité de défense est l'exécution, pas la flotte.", "keyConcepts": [ "Présumer la compromission : la question n'est pas de savoir si un agent agira mal, mais jusqu'où il ira quand ce sera le cas.", "Identité par exécution : chaque exécution porte son propre justificatif éphémère, jamais un compte d'exploitation partagé.", "Confinement plutôt que prévention : le rayon d'impact se conçoit, il ne s'espère pas — une exécution détournée touche une tâche, pas le parc.", "La récupération est une surface de conception : tracer, annuler et arrêter se construisent avant, pas pendant l'incident." ], "definition": "Le système immunitaire agentique est une architecture d'exécution en couches qui permet aux agents d'IA d'agir réellement sur les systèmes de l'entreprise tout en bornant ce qu'une seule exécution peut atteindre, observer ou endommager, grâce à une identité par exécution, un privilège limité à la tâche, un confinement de l'exécution et des sorties, une supervision humaine par le risque et une récupération traçable.", "architecture": [ "L'architecture renverse la question habituelle. Au lieu de demander comment empêcher un agent de se tromper — ce qu'aucune barrière n'obtient de façon fiable face à un système qui raisonne — elle demande jusqu'où l'agent va au moment où il se trompe. Chaque couche est une borne de portée, et les couches sont indépendantes pour que la défaillance de l'une n'ouvre pas les autres.", "L'identité est le socle. Chaque exécution reçoit un justificatif éphémère lié à la tâche, au demandeur et aux outils qu'elle a déclarés. Les agents ne partagent pas de compte de service : quand quelque chose tourne mal, la trace nomme une exécution et non une flotte, et révoquer coûte un jeton au lieu d'une rotation sur tout le parc.", "Le privilège se limite à la tâche et expire avec elle. Le courtier d'outils accorde l'ensemble étroit de capacités que l'exécution a déclaré d'emblée — lire ce ticket, écrire cet enregistrement — et refuse tout le reste, si bien qu'une injection de prompt qui convainc le modèle d'en tenter davantage ne trouve rien à appeler.", "Le confinement suppose que les deux couches précédentes peuvent tomber. L'exécution a lieu dans un bac à sable sans justificatifs ambiants ; la sortie réseau passe par une liste d'autorisation, de sorte que l'exfiltration n'a nulle part où envoyer ; et ce que l'agent produit est encodé à la frontière pour que sa sortie ne devienne pas l'instruction du système suivant.", "La supervision est l'endroit où une personne porte la responsabilité, placée selon le risque et non par défaut : les actions irréversibles ou réglementées s'arrêtent pour approbation, et les résultats peu confiants remontent avec tout le contexte de l'exécution. Mettre une porte partout défait l'automatisation et apprend aux relecteurs à approuver sans lire.", "La récupération referme la boucle. Chaque exécution est tracée sous un identifiant de corrélation unique à travers modèles, outils et reprises ; les actions sont conçues avec leur contrepartie compensatoire lorsque le système sous-jacent le permet ; et un coupe-circuit arrête une classe d'exécutions sans faire tomber la plateforme." ], "flow": [ "1. Demande : une tâche arrive avec son demandeur et un ensemble déclaré d'outils et de portées de données.", "2. Émission : le courtier frappe une identité éphémère, limitée à l'exécution et liée à cette déclaration.", "3. Admission : l'exécution démarre dans un bac à sable, sans justificatifs ambiants et avec une liste de sortie autorisée.", "4. Action : chaque appel d'outil est autorisé contre la portée de l'exécution ; ce qui en sort est refusé et journalisé.", "5. Porte : les actions irréversibles ou réglementées s'arrêtent pour approbation humaine, contexte joint.", "6. Sortie : ce qui est produit est encodé à la frontière pour ne pas être exécuté comme instruction en aval.", "7. Clôture : l'identité expire, la trace est scellée sous son identifiant de corrélation et les actions compensatoires restent disponibles." ], "components": [ "Courtier d'identité par exécution (justificatifs éphémères liés à la tâche)", "Courtier d'outils avec portées de capacité déclarées", "Environnement d'exécution en bac à sable", "Liste de sortie autorisée et contrôles de fuite de données", "Encodeur de frontière de sortie", "Porte d'approbation humaine par le risque", "Trace d'exécution corrélée et journal d'audit", "Actions compensatoires et coupe-circuit" ], "referenceScenario": { "context": "Une entreprise illustrative exploitant des dizaines d'agents sur la billetterie, la finance et la connaissance interne, où chaque agent peut lire et écrire dans des systèmes de référence.", "scenario": "Une étape de récupération ingère un document contenant une instruction injectée demandant à l'agent d'exporter des dossiers clients. Le modèle obtempère, mais l'outil d'export est hors de la portée déclarée de l'exécution et il est refusé ; la tentative est journalisée, la règle d'anomalie arrête l'exécution et l'identifiant de corrélation donne au répondant la chaîne complète en une seule requête.", "technology": "Courtier de justificatifs par exécution, courtier d'outils à portées, exécution en bac à sable, liste de sortie autorisée, encodage de frontière, porte d'approbation par le risque et traçage corrélé.", "load": "Automatisation continue en arrière-plan avec des pics autour des processus métier ; l'action rare et à fort impact est une faible fraction des appels et c'est elle qui porte le risque.", "results": "Cible de référence, non une mesure : une exécution détournée reste bornée à sa portée déclarée, chaque refus est imputable à une exécution, et toute action exécutée peut être tracée et — quand le système sous-jacent le permet — compensée." }, "benefits": [ "Un agent qui se trompe ou qui est détourné coûte une tâche, pas le parc entier.", "Les incidents sont imputables à une exécution et non à un compte partagé : la réponse est ciblée et la révocation peu coûteuse.", "L'injection de prompt perd l'essentiel de sa valeur : convaincre le modèle ne lui accorde pas une capacité qu'il n'a jamais eue.", "L'effort de supervision se concentre sur les actions réellement irréversibles, ce qui préserve le sens de l'approbation." ], "risks": [ "Les portées déclarées s'éloignent de ce dont les agents ont réellement besoin, et les équipes les élargissent jusqu'à rendre le moindre privilège nominal.", "Trop de portes apprend aux relecteurs à approuver sans lire, ce qui est pire que pas de porte du tout.", "Le bac à sable et les courtiers ajoutent de la latence et une surface d'exploitation qu'un petit déploiement ne justifie peut-être pas.", "Certains effets externes n'admettent aucune compensation : un courriel envoyé ou une facture payée ne s'annulent pas." ], "failureModes": [ "Un justificatif de service partagé survit quelque part dans la pile et défait silencieusement l'identité par exécution.", "La liste de sortie est contournée via une destination autorisée qui retransmet elle-même les données.", "Les traces se rompent lors d'une reprise ou d'un changement de modèle, et la chaîne de l'incident ne peut plus être reconstituée.", "La file d'approbation s'engorge et la porte est désactivée « temporairement » pour la vider.", "La sortie d'un outil est traitée comme une entrée de confiance à l'étape suivante, et le confinement se réduit à une frontière unique qui fuit." ], "lessons": [ "Concevez le rayon d'impact avant la capacité : jusqu'où un agent peut aller est une question plus difficile que ce qu'il peut faire, et y répondre d'abord rend le reste traitable.", "L'identité par exécution est la couche porteuse ; sans elle, tout autre contrôle s'applique à un sujet que vous ne savez pas nommer.", "Une porte qui se déclenche sur tout est une porte qui ne se déclenche sur rien : réservez l'approbation humaine à l'irréversible.", "Supposez que le modèle sera convaincu et concevez pour que convaincre ne soit pas autoriser.", "La récupération se construit quand le système est calme ; personne ne conçoit une action compensatoire pendant un incident." ], "kpis": [ { "metric": "Part d'exécutions dotées d'une identité propre et éphémère", "note": "Le contrôle porteur. Tout chiffre en deçà de 100 % signifie qu'un chemin utilise encore un justificatif partagé." }, { "metric": "Tentatives d'outil hors portée, refusées", "note": "Comptées par exécution. Une hausse renseigne sur l'environnement, pas nécessairement sur un défaut de conception." }, { "metric": "Rayon d'impact par exécution", "note": "Nombre de systèmes et d'enregistrements qu'une seule exécution entièrement détournée pourrait atteindre. C'est le nombre que l'architecture existe pour réduire." }, { "metric": "Taux d'actions sous porte et latence d'approbation", "note": "Les deux comptent : un taux trop élevé défait l'automatisation, une latence trop élevée pousse les équipes à désactiver la porte." }, { "metric": "Complétude de la trace", "note": "Part d'exécutions reconstituables de bout en bout sous un identifiant de corrélation, reprises et changements de modèle inclus." }, { "metric": "Délai de révocation", "note": "De la détection à la disparition de la capacité d'une exécution. Avec des justificatifs éphémères, il devrait ressembler à leur expiration, pas à une rotation." } ], "scaling": [ "Les courtiers d'identité et d'outils sont sur le chemin chaud de chaque appel : ils fixent le plafond ; ils sont sans état et passent à l'échelle horizontalement, mais leur latence se paie à chaque usage d'outil.", "Le démarrage du bac à sable domine le coût des exécutions courtes ; garder un pool de bacs chauds échange de la profondeur d'isolement contre de la latence et doit être une décision explicite.", "L'approbation humaine ne passe pas à l'échelle linéairement et constitue la vraie contrainte : l'ensemble sous porte doit rester petit à mesure que la flotte grandit, sinon la file devient la panne.", "Le stockage des traces croît comme exécutions fois appels d'outils ; l'échantillonnage convient à l'observabilité mais pas à l'audit, donc les deux politiques de rétention doivent être distinctes." ], "examples": [ "Une instruction injectée dans un document récupéré demande un export de données ; l'outil est hors de la portée de l'exécution, l'appel est refusé et journalisé.", "Un agent financier prépare un paiement et une personne l'approuve avant exécution, la trace de l'exécution jointe à l'approbation.", "Une classe d'agents défaillante est arrêtée par le coupe-circuit pendant que le reste de la flotte continue.", "Un incident est reconstitué à partir d'un seul identifiant de corrélation couvrant trois modèles, neuf appels d'outils et deux reprises." ], "faqs": [ { "q": "Pourquoi un système immunitaire plutôt qu'un pare-feu ?", "a": "Un pare-feu suppose une frontière entre l'intérieur et l'extérieur. Une entreprise qui exploite des agents n'a pas cette frontière : l'agent est déjà à l'intérieur, agissant avec de vrais justificatifs. Un système immunitaire tient l'intrusion pour normale et investit dans la reconnaissance, le confinement et la réparation plutôt que dans un périmètre." }, { "q": "N'est-ce pas du moindre privilège avec des étapes en plus ?", "a": "Le moindre privilège est l'une des cinq couches et la plus familière. Ce que soutient l'architecture, c'est qu'elle ne suffit pas seule : sans identité par exécution vous ne pouvez pas limiter le privilège à un sujet, et sans confinement ni récupération une exécution correctement bornée qui dérape malgré tout n'a ni borne ni marche arrière." }, { "q": "Cela arrête-t-il l'injection de prompt ?", "a": "Non, et considérer un contrôle comme l'arrêtant est justement l'erreur. Cela rend l'injection bon marché à survivre : convaincre le modèle de tenter une action n'équivaut pas à ce que cette action soit autorisée, et la tentative refusée est elle-même un signal." }, { "q": "Quelle est la version minimale viable ?", "a": "Identité par exécution et accès aux outils limité à la tâche. Ces deux-là donnent l'imputabilité et une borne. Le confinement, la porte et les actions compensatoires pèsent d'autant plus que les actions deviennent irréversibles." }, { "q": "Quel rapport avec les cadres de gouvernance ?", "a": "C'est leur expression à l'exécution. Le NIST AI RMF et l'ISO 42001 exigent responsabilité et traçabilité ; l'OWASP LLM Top 10 et MITRE ATLAS décrivent les attaques. Cette architecture est l'endroit où ces obligations deviennent des identités, des portées, des bacs à sable et des traces." } ] }, "de": { "name": "Agentisches Immunsystem", "summary": "Referenzarchitektur, um KI-Agenten im Unternehmen zu betreiben, ohne das Vertrauen auf einen einzelnen zu bündeln. Fünf Schichten – Identität, minimale Rechte, Eindämmung, Aufsicht und Wiederherstellung – gehen davon aus, dass irgendein Agent irgendwann falsch handelt oder unterwandert wird, und machen diesen Tag überlebbar statt katastrophal. Verteidigungseinheit ist der einzelne Lauf, nicht die Flotte.", "keyConcepts": [ "Kompromittierung voraussetzen: Die Frage ist nicht, ob ein Agent falsch handelt, sondern wie weit er dann reicht.", "Identität je Lauf: Jeder Lauf trägt sein eigenes kurzlebiges Credential, nie ein geteiltes Betriebskonto.", "Eindämmung vor Verhinderung: Der Schadensradius wird entworfen, nicht erhofft – ein unterwanderter Lauf trifft eine Aufgabe, nicht den Bestand.", "Wiederherstellung ist eine Entwurfsfläche: Nachverfolgen, Rückgängigmachen und Anhalten werden vorher gebaut, nicht im Vorfall improvisiert." ], "definition": "Das agentische Immunsystem ist eine geschichtete Laufzeitarchitektur, die KI-Agenten echtes Handeln auf Unternehmenssystemen erlaubt und zugleich begrenzt, was ein einzelner Lauf erreichen, einsehen oder beschädigen kann – über Identität je Lauf, auf die Aufgabe beschränkte Rechte, Eindämmung von Ausführung und Ausgang, risikobasierte menschliche Aufsicht und nachvollziehbare Wiederherstellung.", "architecture": [ "Die Architektur dreht die übliche Frage um. Statt zu fragen, wie man einen Agenten vom Fehler abhält – was keine Leitplanke gegenüber einem schlussfolgernden System verlässlich schafft –, fragt sie, wie weit der Agent in dem Moment reicht, in dem er sich irrt. Jede Schicht ist eine Reichweitengrenze, und die Schichten sind unabhängig, damit der Ausfall einer nicht die übrigen öffnet.", "Identität ist das Fundament. Jeder Lauf erhält ein kurzlebiges Credential, gebunden an die Aufgabe, den anfragenden Principal und die Werkzeuge, die er angemeldet hat. Agenten teilen sich kein Dienstkonto: Geht etwas schief, benennt die Spur einen Lauf und keine Flotte, und Entzug kostet ein Token statt einer Rotation über den ganzen Bestand.", "Rechte gelten für die Aufgabe und verfallen mit ihr. Der Werkzeug-Broker gewährt genau die schmale Menge an Fähigkeiten, die der Lauf vorab angemeldet hat – dieses Ticket lesen, diesen Datensatz schreiben – und verweigert alles andere. Eine Prompt-Injektion, die das Modell zu mehr überredet, findet nichts zum Aufrufen.", "Eindämmung setzt voraus, dass die beiden vorherigen Schichten fallen können. Ausgeführt wird in einer Sandbox ohne Umgebungs-Credentials; ausgehender Netzverkehr läuft über eine Allowlist, sodass Exfiltration kein Ziel hat; und was der Agent erzeugt, wird an der Grenze kodiert, damit seine Ausgabe nicht zur Anweisung des nächsten Systems wird.", "Aufsicht ist der Ort, an dem ein Mensch die Verantwortung trägt – nach Risiko platziert, nicht als Voreinstellung: Unumkehrbare oder regulierte Aktionen halten zur Freigabe an, und Ergebnisse geringer Zuversicht eskalieren mit dem vollen Laufkontext. Alles zu gaten zerstört die Automatisierung und erzieht Prüfende zum Durchklicken.", "Wiederherstellung schließt den Kreis. Jeder Lauf wird unter einer einzigen Korrelations-ID über Modelle, Werkzeuge und Wiederholungen hinweg verfolgt; Aktionen werden mit einem kompensierenden Gegenstück entworfen, wo das Zielsystem es zulässt; und ein Notaus stoppt eine Klasse von Läufen, ohne die Plattform mitzunehmen." ], "flow": [ "1. Anfrage: Eine Aufgabe trifft ein, mit anfragendem Principal und angemeldeten Werkzeugen und Datenbereichen.", "2. Ausstellung: Der Broker prägt eine kurzlebige, laufgebundene Identität zu dieser Anmeldung.", "3. Zulassung: Der Lauf startet in einer Sandbox, ohne Umgebungs-Credentials und mit Ausgangs-Allowlist.", "4. Handlung: Jeder Werkzeugaufruf wird gegen den Bereich des Laufs autorisiert; alles darüber hinaus wird verweigert und protokolliert.", "5. Gate: Unumkehrbare oder regulierte Aktionen halten zur menschlichen Freigabe an, mit angehängtem Kontext.", "6. Ausgabe: Erzeugtes wird an der Grenze kodiert, damit es nachgelagert nicht als Anweisung ausgeführt wird.", "7. Abschluss: Die Identität verfällt, die Spur wird unter ihrer Korrelations-ID versiegelt, kompensierende Aktionen bleiben verfügbar." ], "components": [ "Identitäts-Broker je Lauf (kurzlebige, aufgabengebundene Credentials)", "Werkzeug-Broker mit angemeldeten Fähigkeitsbereichen", "Sandbox-Ausführungsumgebung", "Ausgangs-Allowlist und Datenabfluss-Kontrollen", "Grenz-Kodierer für Ausgaben", "Risikobasiertes menschliches Freigabe-Gate", "Korrelierte Laufspur und Auditprotokoll", "Kompensierende Aktionen und Notaus" ], "referenceScenario": { "context": "Ein illustratives Unternehmen mit Dutzenden Agenten in Ticketing, Finanzen und internem Wissen, in dem jeder Agent Systeme der Aufzeichnung lesen und schreiben kann.", "scenario": "Ein Retrieval-Schritt nimmt ein Dokument auf, das eine eingeschleuste Anweisung enthält, Kundendaten zu exportieren. Das Modell folgt, doch das Export-Werkzeug liegt außerhalb des angemeldeten Bereichs des Laufs und wird verweigert; der Versuch wird protokolliert, die Anomalieregel stoppt den Lauf, und die Korrelations-ID liefert der Reaktion die vollständige Kette in einer Abfrage.", "technology": "Credential-Broker je Lauf, Werkzeug-Broker mit Bereichen, Sandbox-Ausführung, Ausgangs-Allowlist, Grenzkodierung, risikobasiertes Freigabe-Gate und korrelierte Ablaufverfolgung.", "load": "Dauerhafte Hintergrundautomatisierung mit Spitzen um Geschäftsprozesse; die seltene, folgenschwere Aktion ist ein kleiner Anteil der Aufrufe und trägt das Risiko.", "results": "Referenzziel, keine Messung: Ein unterwanderter Lauf bleibt auf seinen angemeldeten Bereich begrenzt, jede Verweigerung ist einem Lauf zurechenbar, und jede ausgeführte Aktion lässt sich verfolgen und – wo das Zielsystem es erlaubt – kompensieren." }, "benefits": [ "Ein falscher oder unterwanderter Agent kostet eine Aufgabe, nicht den Bestand.", "Vorfälle sind einem Lauf zurechenbar statt einem geteilten Konto: Die Reaktion ist gezielt und der Entzug billig.", "Prompt-Injektion verliert den größten Teil ihres Werts: Das Modell zu überreden verschafft ihm keine Fähigkeit, die es nie hatte.", "Der Aufsichtsaufwand konzentriert sich auf die wirklich unumkehrbaren Aktionen, und die Freigabe behält dadurch ihre Bedeutung." ], "risks": [ "Angemeldete Bereiche driften von dem ab, was Agenten wirklich brauchen, und Teams weiten sie aus, bis minimale Rechte nur noch nominell sind.", "Zu viel zu gaten erzieht Prüfende zum Freigeben ohne Lesen – schlimmer als gar kein Gate.", "Sandbox und Broker fügen Latenz und Betriebsfläche hinzu, die kleine Installationen womöglich nicht rechtfertigen.", "Manche externen Wirkungen lassen sich nicht kompensieren: Eine gesendete E-Mail oder eine bezahlte Rechnung nimmt man nicht zurück." ], "failureModes": [ "Ein geteiltes Dienst-Credential überlebt irgendwo im Stack und hebelt die Identität je Lauf still aus.", "Die Ausgangs-Allowlist wird über ein erlaubtes Ziel umgangen, das die Daten selbst weiterleitet.", "Spuren brechen bei einer Wiederholung oder einem Modellwechsel, und die Vorfallskette lässt sich nicht mehr rekonstruieren.", "Die Freigabe-Warteschlange staut sich, und das Gate wird „vorübergehend“ abgeschaltet, um sie zu leeren.", "Werkzeugausgabe wird im nächsten Schritt als vertrauenswürdige Eingabe behandelt – Eindämmung schrumpft auf eine einzige, undichte Grenze." ], "lessons": [ "Entwerfe den Schadensradius vor der Fähigkeit: Wie weit ein Agent reichen darf ist die schwerere Frage als was er tun darf, und sie zuerst zu beantworten macht den Rest handhabbar.", "Identität je Lauf ist die tragende Schicht; ohne sie richtet sich jede andere Kontrolle gegen ein Subjekt, das man nicht benennen kann.", "Ein Gate, das bei allem auslöst, löst bei nichts aus – menschliche Freigabe bleibt dem Unumkehrbaren vorbehalten.", "Nimm an, das Modell wird überredet, und entwirf so, dass Überreden nicht Autorisieren ist.", "Wiederherstellung wird gebaut, solange das System ruhig ist; niemand entwirft eine kompensierende Aktion mitten im Vorfall." ], "kpis": [ { "metric": "Anteil Läufe mit eigener, kurzlebiger Identität", "note": "Die tragende Kontrolle. Alles unter 100 % heißt, dass ein Pfad noch ein geteiltes Credential verwendet." }, { "metric": "Verweigerte Werkzeugversuche außerhalb des Bereichs", "note": "Je Lauf gezählt. Ein Anstieg sagt etwas über die Umgebung, nicht zwingend über einen Entwurfsfehler." }, { "metric": "Schadensradius je Lauf", "note": "Wie viele Systeme und Datensätze ein einzelner, vollständig unterwanderter Lauf erreichen könnte. Genau die Zahl, die diese Architektur schrumpfen soll." }, { "metric": "Gate-Quote und Freigabelatenz", "note": "Beides zählt: Eine zu hohe Quote zerstört die Automatisierung, eine zu hohe Latenz bringt Teams dazu, das Gate abzuschalten." }, { "metric": "Vollständigkeit der Spur", "note": "Anteil der Läufe, die sich unter einer Korrelations-ID durchgängig rekonstruieren lassen, samt Wiederholungen und Modellwechseln." }, { "metric": "Zeit bis zum Entzug", "note": "Von der Erkennung bis zum Verschwinden der Fähigkeit eines Laufs. Mit kurzlebigen Credentials sollte das eher der Ablaufzeit gleichen als einer Rotation." } ], "scaling": [ "Identitäts- und Werkzeug-Broker liegen im heißen Pfad jedes Aufrufs und setzen damit die Obergrenze; sie sind zustandslos und skalieren horizontal, aber ihre Latenz wird bei jedem Werkzeugeinsatz bezahlt.", "Der Sandbox-Start dominiert die Kosten kurzer Läufe; ein Pool warmer Sandboxes tauscht Isolationstiefe gegen Latenz und sollte eine ausdrückliche Entscheidung sein.", "Menschliche Freigabe skaliert nicht linear und ist die eigentliche Grenze: Die gegatete Menge muss klein bleiben, während die Flotte wächst, sonst wird die Warteschlange zum Ausfall.", "Spurspeicher wächst mit Läufen mal Werkzeugaufrufen; Sampling taugt für Observability, nicht für Audit – die beiden Aufbewahrungsrichtlinien gehören getrennt." ], "examples": [ "Eine eingeschleuste Anweisung in einem abgerufenen Dokument verlangt einen Datenexport; das Werkzeug liegt außerhalb des Laufbereichs, der Aufruf wird verweigert und protokolliert.", "Ein Finanzagent entwirft eine Zahlung, und ein Mensch gibt sie vor der Ausführung frei – die Laufspur hängt an der Freigabe.", "Eine fehlverhaltende Agentenklasse wird per Notaus gestoppt, während der Rest der Flotte weiterläuft.", "Ein Vorfall wird aus einer einzigen Korrelations-ID rekonstruiert, die drei Modelle, neun Werkzeugaufrufe und zwei Wiederholungen umfasst." ], "faqs": [ { "q": "Warum ein Immunsystem und keine Firewall?", "a": "Eine Firewall setzt eine Grenze zwischen innen und außen voraus. Ein Unternehmen, das Agenten betreibt, hat diese Grenze nicht: Der Agent ist bereits innen und handelt mit echten Credentials. Ein Immunsystem hält Eindringen für normal und investiert in Erkennung, Eindämmung und Reparatur statt in einen Perimeter." }, { "q": "Ist das nicht minimale Rechte mit Zusatzschritten?", "a": "Minimale Rechte sind eine der fünf Schichten und die bekannteste. Die These der Architektur ist, dass sie allein nicht genügen: Ohne Identität je Lauf lassen sich Rechte keinem Subjekt zuschneiden, und ohne Eindämmung und Wiederherstellung hat ein korrekt beschnittener Lauf, der dennoch schiefgeht, weder Grenze noch Rückweg." }, { "q": "Stoppt das Prompt-Injektion?", "a": "Nein, und irgendeine Kontrolle so zu behandeln, als stoppe sie das, ist genau der Fehler. Es macht Injektion billig überlebbar: Das Modell zu einer Aktion zu überreden ist nicht dasselbe, wie dass diese Aktion autorisiert wäre – und der verweigerte Versuch ist selbst ein Signal." }, { "q": "Was ist die minimal tragfähige Fassung?", "a": "Identität je Lauf und aufgabenbeschränkter Werkzeugzugriff. Diese beiden liefern Zurechenbarkeit und eine Grenze. Eindämmung, Gate und kompensierende Aktionen wiegen umso schwerer, je unumkehrbarer die Aktionen werden." }, { "q": "Wie verhält sich das zu den Governance-Rahmenwerken?", "a": "Es ist deren Ausdruck zur Laufzeit. NIST AI RMF und ISO 42001 verlangen Verantwortlichkeit und Nachvollziehbarkeit; OWASP LLM Top 10 und MITRE ATLAS beschreiben die Angriffe. In dieser Architektur werden diese Pflichten zu Identitäten, Bereichen, Sandboxes und Spuren." } ] }, "ja": { "name": "エージェント免疫系", "summary": "特定のエージェントに信頼を集中させずに企業で AI エージェントを運用するためのリファレンスアーキテクチャ。アイデンティティ、最小権限、封じ込め、監督、復旧という五つの層は、いずれかのエージェントがいつか誤るか乗っ取られることを前提とし、その日を壊滅ではなく生存可能な出来事にする。防御の単位は個々の実行であり、群ではない。", "keyConcepts": [ "侵害を前提とする。問うべきはエージェントが誤るかどうかではなく、誤った瞬間にどこまで届くかである。", "実行ごとのアイデンティティ。各実行は自分専用の短命な資格情報を持ち、共有の運用アカウントは使わない。", "予防より封じ込め。影響範囲は祈るものではなく設計するもので、乗っ取られた実行が及ぶのは一つのタスクであって全体ではない。", "復旧は設計面である。追跡・取り消し・停止は事前に作るものであり、事故の最中に即席で用意するものではない。" ], "definition": "エージェント免疫系とは、実行ごとのアイデンティティ、タスクに限定した権限、実行と外向き通信の封じ込め、リスクに応じた人間の監督、追跡可能な復旧によって、単一の実行が到達・観測・破壊できる範囲を限定しながら、AI エージェントに企業システム上での実際の行動を許す階層型のランタイムアーキテクチャである。", "architecture": [ "このアーキテクチャは通常の問いを反転させる。推論する系に対してどんなガードレールも確実には達成できない「どうすればエージェントに誤らせないか」ではなく、「誤ったその瞬間にどこまで届くか」を問う。各層は到達範囲の限界であり、層は互いに独立しているため、一つが破れても残りが開くことはない。", "土台はアイデンティティである。各実行には、タスク・要求主体・宣言したツールに結び付いた短命な資格情報が発行される。エージェントはサービスアカウントを共有しない。問題が起きたとき、痕跡が名指すのは群ではなく一つの実行であり、失効の代償は全体のローテーションではなくトークン一つで済む。", "権限はタスクに限定され、タスクとともに失効する。ツールブローカーは実行が事前に宣言した狭い能力の集合だけを与え——このチケットを読む、このレコードを書く——それ以外を拒む。したがって、もっと多くを試みるようモデルを説得したプロンプトインジェクションは、呼ぶ先を見つけられない。", "封じ込めは、前の二層が破られうることを前提とする。実行は環境資格情報を持たないサンドボックスで行われ、外向き通信は許可リストを通るため持ち出しの送り先がなく、エージェントの生成物は境界で符号化され、その出力が次の系の命令になることを防ぐ。", "監督は人が責任を負う場所であり、既定ではなくリスクに応じて置かれる。不可逆な行為や規制対象の行為は承認のために止まり、確信の低い結果は実行の全文脈を添えてエスカレーションされる。何にでもゲートを置けば自動化は死に、レビュー担当者は読まずに承認する習慣を身につける。", "復旧が輪を閉じる。各実行はモデル・ツール・再試行をまたいで単一の相関 ID の下に追跡され、対象システムが許す限り行為には補償操作が対になって設計され、非常停止はプラットフォームを落とさずに特定クラスの実行だけを止める。" ], "flow": [ "1. 要求：タスクが、要求主体と宣言済みのツール・データ範囲とともに到着する。", "2. 発行：ブローカーがその宣言に紐づく、実行限定で短命なアイデンティティを鋳造する。", "3. 受入：実行は環境資格情報を持たないサンドボックスで、外向き許可リストとともに開始される。", "4. 行動：ツール呼び出しはすべて実行の範囲に照らして認可され、範囲外は拒否のうえ記録される。", "5. ゲート：不可逆・規制対象の行為は、文脈を添えて人間の承認を待って停止する。", "6. 出力：生成物は境界で符号化され、下流で命令として実行されないようにする。", "7. 終了：アイデンティティが失効し、痕跡は相関 ID の下に封印され、補償操作は引き続き利用できる。" ], "components": [ "実行ごとのアイデンティティ発行基盤（タスクに紐づく短命な資格情報）", "能力範囲を宣言するツールブローカー", "サンドボックス実行環境", "外向き許可リストとデータ持ち出し制御", "出力境界の符号化器", "リスクに応じた人間の承認ゲート", "相関付けされた実行トレースと監査ログ", "補償操作と非常停止" ], "referenceScenario": { "context": "チケット処理・財務・社内ナレッジにまたがって数十のエージェントを運用し、各エージェントが記録システムを読み書きできる、例示的な企業。", "scenario": "検索工程が、顧客レコードを書き出すよう指示する注入文を含む文書を取り込む。モデルはそれに従うが、書き出しツールは実行が宣言した範囲の外にあり拒否される。試行は記録され、異常検知の規則が実行を停止し、相関 ID によって対応者は一度の照会で連鎖の全体を得る。", "technology": "実行ごとの資格情報発行、範囲付きツールブローカー、サンドボックス実行、外向き許可リスト、境界符号化、リスク承認ゲート、相関トレース。", "load": "業務プロセスの前後で山を作る、継続的な裏方の自動化。稀で影響の大きい行為は呼び出し全体のごく一部であり、そこにリスクが集中する。", "results": "測定値ではなく参照目標：乗っ取られた実行は宣言範囲に閉じ込められ、あらゆる拒否は特定の実行に帰属し、実行された行為は追跡でき、対象システムが許す場合は補償できる。" }, "benefits": [ "誤った、あるいは乗っ取られたエージェントの代償は一つのタスクであって、全体ではない。", "事故は共有アカウントではなく一つの実行に帰属するため、対応は的を絞れ、失効は安く済む。", "プロンプトインジェクションはほとんど価値を失う。モデルを説得しても、元々持たない能力は与えられない。", "監督の労力が本当に不可逆な行為に集中し、承認が意味を保ち続ける。" ], "risks": [ "宣言された範囲が実際の必要から乖離し、チームが広げ続けた結果、最小権限が名ばかりになる。", "ゲートを置きすぎると、レビュー担当者は読まずに承認するようになり、ゲートがないより悪くなる。", "サンドボックスとブローカーは待ち時間と運用面を増やし、小規模な導入では割に合わないことがある。", "外部への影響には補償できないものがある。送信済みのメールや支払済みの請求は元に戻らない。" ], "failureModes": [ "共有のサービス資格情報がスタックのどこかに生き残り、実行ごとのアイデンティティを静かに無効化する。", "許可リストが、自らデータを転送する許可済みの宛先を経由して回避される。", "再試行やモデル切り替えでトレースが途切れ、事故の連鎖を再構成できなくなる。", "承認の待ち行列が詰まり、それを捌くためにゲートが「一時的に」無効化される。", "ツールの出力が次工程で信頼できる入力として扱われ、封じ込めが漏れのある単一境界に縮む。" ], "lessons": [ "能力より先に影響範囲を設計する。エージェントが何をしてよいかより、どこまで届いてよいかの方が難しい問いであり、先に答えると残りが扱いやすくなる。", "実行ごとのアイデンティティは荷重を支える層である。それがなければ、他のあらゆる統制は名指せない主体に対して適用される。", "何にでも作動するゲートは、何にも作動しないゲートである。人間の承認は不可逆なものに限る。", "モデルは説得されるものと想定し、説得が認可にならないように設計する。", "復旧は系が平静なうちに作る。事故の最中に補償操作を設計する者はいない。" ], "kpis": [ { "metric": "固有かつ短命なアイデンティティを持つ実行の割合", "note": "荷重を支える統制。100 % に満たなければ、どこかの経路がまだ共有資格情報を使っている。" }, { "metric": "範囲外ツール試行の拒否件数", "note": "実行ごとに数える。増加は環境について語るものであり、必ずしも設計の失敗ではない。" }, { "metric": "実行あたりの影響範囲", "note": "完全に乗っ取られた単一の実行が到達しうるシステムとレコードの数。このアーキテクチャが縮めるために存在する数値。" }, { "metric": "ゲート対象率と承認待ち時間", "note": "どちらも重要。率が高すぎれば自動化が死に、待ち時間が長すぎればチームがゲートを切る。" }, { "metric": "トレースの完全性", "note": "再試行やモデル切り替えを含め、単一の相関 ID で端から端まで再構成できる実行の割合。" }, { "metric": "失効までの時間", "note": "検知から実行の能力が消えるまで。短命な資格情報なら、ローテーションではなく有効期限に近いはずである。" } ], "scaling": [ "アイデンティティとツールのブローカーは全呼び出しのホットパスにあり、上限を決める。状態を持たず水平に伸びるが、その待ち時間はツール利用のたびに支払われる。", "短い実行ではサンドボックスの起動が費用を支配する。温めたサンドボックスをプールすると分離の深さと待ち時間を交換することになり、明示的な判断であるべきだ。", "人間の承認は線形には伸びず、真の制約になる。群が育つにつれてゲート対象は小さく保たねばならず、さもなければ待ち行列そのものが障害になる。", "トレースの保管量は実行数×ツール呼び出し数で増える。サンプリングは可観測性には妥当だが監査には使えないため、保持方針は二つに分けるべきである。" ], "examples": [ "取得した文書に注入された指示がデータ書き出しを要求するが、そのツールは実行範囲の外にあり、呼び出しは拒否され記録される。", "財務エージェントが支払いを起案し、人が実行前に承認する。承認には実行トレースが添付される。", "挙動の悪いエージェント種別が非常停止で止められ、残りの群は動き続ける。", "三つのモデル、九回のツール呼び出し、二回の再試行にまたがる単一の相関 ID から事故が再構成される。" ], "faqs": [ { "q": "なぜファイアウォールではなく免疫系なのか。", "a": "ファイアウォールは内と外の境界を前提とする。エージェントを運用する企業にその境界はない。エージェントはすでに内側にいて、本物の資格情報で動いている。免疫系は侵入を常態とみなし、境界線ではなく認識・封じ込め・修復に投資する。" }, { "q": "手順が増えただけの最小権限では。", "a": "最小権限は五つの層の一つで、最もよく知られたものだ。このアーキテクチャの主張は、それだけでは足りないという点にある。実行ごとのアイデンティティがなければ権限を主体に絞れず、封じ込めと復旧がなければ、正しく絞られていてもなお誤った実行には限界も引き返しもない。" }, { "q": "これでプロンプトインジェクションは止まるのか。", "a": "止まらない。そして、どれかの統制がそれを止めると考えることこそが誤りである。これが行うのは、インジェクションを安く生き延びられるようにすることだ。行為を試みるようモデルを説得することと、その行為が認可されていることは同じではなく、拒否された試行自体が信号になる。" }, { "q": "最小限に成立する版は。", "a": "実行ごとのアイデンティティと、タスクに限定したツールアクセス。この二つが帰属と限界を与える。封じ込め、ゲート、補償操作は、行為が不可逆になるほど重みを増す。" }, { "q": "ガバナンスの枠組みとの関係は。", "a": "その実行時における表現である。NIST AI RMF と ISO 42001 は責任と追跡可能性を求め、OWASP LLM Top 10 と MITRE ATLAS は攻撃を記述する。このアーキテクチャは、それらの義務がアイデンティティ・範囲・サンドボックス・トレースになる場所だ。" } ] }, "zh": { "name": "智能体免疫系统", "summary": "一套参考架构，用于在企业中运行 AI 智能体而不把信任集中于其中任何一个。身份、最小权限、围堵、监督与恢复这五层，假定总有某个智能体终将出错或被劫持，并让那一天变得可以承受而非灾难性的。防御的单位是单次运行，而不是整支队伍。", "keyConcepts": [ "预设已被攻破：问题不是智能体会不会做错，而是它做错时能够触及多远。", "按次运行的身份：每次运行携带自己的短时凭据，绝不使用共享的运维账号。", "围堵先于预防：影响半径是设计出来的，不是指望出来的——被劫持的一次运行波及一项任务，而非整片资产。", "恢复是一个设计面：追踪、撤销与停止要事先建好，而不是事故中临时凑出来。" ], "definition": "智能体免疫系统是一种分层的运行时架构，它通过按次运行的身份、限定于任务的权限、执行与出网的围堵、按风险设置的人工监督以及可追溯的恢复，在允许 AI 智能体对企业系统采取真实行动的同时，限定单次运行所能触及、观察或破坏的范围。", "architecture": [ "这套架构把惯常的问题反了过来。它不问如何阻止智能体犯错——面对一个会推理的系统，没有任何护栏能可靠做到——而是问它犯错的那一刻能够触及多远。每一层都是触及范围的边界，各层彼此独立，因此其中一层失守不会把其余各层一并打开。", "身份是地基。每次运行都会获得一份短时凭据，绑定到任务、发起主体以及它声明需要的工具。智能体之间不共享服务账号：出问题时，痕迹指向的是一次运行而非一支队伍，撤销的代价是一枚令牌，而不是整片资产的轮换。", "权限限定于任务，并随任务失效。工具代理只授予运行事先声明的那一小组能力——读这张工单、写这条记录——并拒绝其余一切；于是，一次说服模型去尝试更多的提示注入，找不到可以调用的对象。", "围堵假定前两层可能被攻破。执行发生在没有环境凭据的沙箱中；出网流量经过允许列表，因此外泄无处可送；而智能体产出的一切都会在边界处编码，使其输出不会成为下一个系统的指令。", "监督是由人承担问责的位置，按风险而非默认设置：不可逆或受监管的动作会暂停等待批准，低置信度的结果会带着完整的运行上下文上报。对一切都设闸会毁掉自动化，并训练评审者不读就点通过。", "恢复闭合了这个环。每次运行都在单一关联 ID 之下跨模型、工具与重试被追踪；在目标系统允许的情况下，动作都设计有配对的补偿操作；紧急停止可以停下一类运行，而不必让整个平台停摆。" ], "flow": [ "1. 请求：任务到达，附带发起主体以及声明的工具与数据范围。", "2. 签发：代理铸造一份绑定该声明、限定于本次运行的短时身份。", "3. 准入：运行在沙箱中启动，没有环境凭据，并带有出网允许列表。", "4. 行动：每次工具调用都按本次运行的范围授权；范围之外的一律拒绝并记录。", "5. 闸门：不可逆或受监管的动作暂停等待人工批准，并附上上下文。", "6. 输出：产出在边界处编码，使其在下游不会被当作指令执行。", "7. 收尾：身份失效，痕迹在其关联 ID 之下封存，补偿操作仍然可用。" ], "components": [ "按次运行的身份签发方（绑定任务的短时凭据）", "带有声明能力范围的工具代理", "沙箱执行环境", "出网允许列表与数据外泄控制", "输出边界编码器", "按风险设置的人工批准闸门", "关联的运行追踪与审计日志", "补偿操作与紧急停止" ], "referenceScenario": { "context": "一家示例企业，在工单、财务与内部知识领域运行着数十个智能体，每个智能体都可以读写记录系统。", "scenario": "检索环节摄入了一份文档，其中注入的指令要求智能体导出客户记录。模型照做了，但导出工具不在本次运行声明的范围内，调用被拒绝；尝试被记录，异常规则停止了该次运行，关联 ID 让响应者一次查询就拿到完整链路。", "technology": "按次运行的凭据签发、带范围的工具代理、沙箱执行、出网允许列表、边界编码、按风险的批准闸门与关联追踪。", "load": "持续的后台自动化，并在业务流程前后形成尖峰；稀少而影响重大的动作只占调用的一小部分，风险恰恰集中在那里。", "results": "参考目标而非实测结果：被劫持的运行被限定在其声明范围内，每一次拒绝都可归因到具体运行，任何已执行的动作都可追踪，并在目标系统允许时可被补偿。" }, "benefits": [ "一个出错或被劫持的智能体，代价是一项任务，而不是整片资产。", "事故可归因到一次运行而非共享账号，因此响应有的放矢，撤销成本低廉。", "提示注入大部分价值落空：说服模型并不能赋予它从未拥有的能力。", "监督精力集中在真正不可逆的动作上，批准因此仍然有分量。" ], "risks": [ "声明的范围与智能体真实所需逐渐脱节，团队不断放宽，直到最小权限只剩名义。", "设闸过多会训练评审者不读就批准，那比不设闸更糟。", "沙箱与代理带来额外的时延与运维面，小规模部署未必值得。", "有些对外的影响无法补偿：已发出的邮件、已支付的账单都收不回来。" ], "failureModes": [ "某处栈中残留一份共享服务凭据，悄无声息地瓦解了按次运行的身份。", "出网允许列表被绕过——经由一个本身会转发数据的已批准目的地。", "追踪在一次重试或一次模型切换处断裂，事故链条再也无法重建。", "批准队列积压，闸门被「临时」关闭以便清空队列。", "工具输出在下一步被当作可信输入，围堵退化为一道会漏的单一边界。" ], "lessons": [ "先设计影响半径，再谈能力：智能体能触及多远，是比它能做什么更难的问题，先回答它会让其余部分变得可处理。", "按次运行的身份是承重的一层；没有它，其他任何管控都是针对一个你叫不出名字的主体施加的。", "对一切都触发的闸门等于什么都不触发：把人工批准留给不可逆的动作。", "假定模型会被说服，并据此设计，使说服不等于授权。", "恢复要在系统平静时建好；没有人会在事故当中设计补偿操作。" ], "kpis": [ { "metric": "拥有独立短时身份的运行占比", "note": "承重的那项管控。任何低于 100% 的数字都意味着仍有路径在使用共享凭据。" }, { "metric": "被拒绝的越界工具调用", "note": "按运行计数。数字上升说明的是环境，未必是设计的失败。" }, { "metric": "每次运行的影响半径", "note": "单次运行若被完全劫持所能触及的系统与记录数量。这正是该架构存在的目的所要缩小的数字。" }, { "metric": "设闸动作比例与批准时延", "note": "两者都重要：比例过高会毁掉自动化，时延过长会让团队关掉闸门。" }, { "metric": "追踪完整度", "note": "能在单一关联 ID 之下端到端重建的运行占比，包含重试与模型切换。" }, { "metric": "撤销所需时间", "note": "从检测到一次运行的能力消失为止。使用短时凭据时，这个时间应接近其到期时长，而不是一次轮换。" } ], "scaling": [ "身份代理与工具代理位于每次调用的热路径上，因而决定了上限；它们无状态、可水平扩展，但其时延在每次使用工具时都要支付。", "对短运行而言，沙箱启动主导成本；用温沙箱池来换取时延，是以隔离深度作交换，应当是一个明确的决定。", "人工批准不是线性扩展的，才是真正的约束：随着队伍变大，设闸的集合必须保持很小，否则队列本身就成了故障。", "追踪存储随运行数乘以工具调用数增长；采样对可观测性可行，对审计不可行，因此两套留存策略应当分开。" ], "examples": [ "检索到的文档中注入的指令要求导出数据；该工具不在本次运行范围内，调用被拒绝并记录。", "财务智能体起草一笔付款，由人在执行前批准，批准上附有该次运行的追踪。", "行为异常的一类智能体被紧急停止，队伍中其余部分继续运行。", "一次事故从单一关联 ID 重建出来，跨越三个模型、九次工具调用与两次重试。" ], "faqs": [ { "q": "为什么是免疫系统而不是防火墙？", "a": "防火墙假定内外之间存在边界。运行智能体的企业没有这条边界：智能体已经在里面，带着真实凭据在行动。免疫系统把入侵视为常态，把投入放在识别、围堵与修复上，而不是放在一道周界上。" }, { "q": "这不就是多绕几步的最小权限吗？", "a": "最小权限是五层中的一层，也是最为人熟知的一层。这套架构的主张是：单靠它并不够。没有按次运行的身份，权限就无法收敛到一个主体；没有围堵与恢复，一次范围正确却仍然出错的运行既没有边界也没有退路。" }, { "q": "这能挡住提示注入吗？", "a": "挡不住，而把任何一项管控当成能挡住它，恰恰是那个错误。它做的是让注入变得便宜到可以幸存：说服模型去尝试某个动作，和这个动作被授权并不是一回事，而被拒绝的尝试本身就是一个信号。" }, { "q": "最小可行版本是什么？", "a": "按次运行的身份，加上限定于任务的工具访问。这两样给出归因与边界。围堵、闸门与补偿操作的分量，随动作越发不可逆而越发重要。" }, { "q": "它和治理框架是什么关系？", "a": "它是这些框架在运行时的表达。NIST AI RMF 与 ISO 42001 要求问责与可追溯，OWASP LLM Top 10 与 MITRE ATLAS 描述攻击。这套架构正是那些义务变成身份、范围、沙箱与追踪的地方。" } ] } } } ] }