Gefedereerde AI-architecturen: een zorgvuldige evenwichtsoefening

Ondernemingen die AI-agents op meerdere domeinplatforms inzetten, staan voor een kritieke governance-uitdaging: domeinspecifieke systemen gaan goed om met lokale agents, maar cross-domain agents gaan verder dan veronderstelde vertrouwens- en governancekaders. Dit creëert risico's die traditionele beveiligingsbenaderingen vaak niet dekken. Een dual-track AI-platformstrategie lost deze spanning op.

• Gebruik domeinspecifieke platforms voor domeinspecifieke, laag-risico agents: Veel grote platformen (zoals ServiceNow, Salesforce, SAP) beschikken nu over volwassen, ingebouwde agentic AI-functionaliteit. In een gefedereerde architectuur moeten agents die strikt binnen de grenzen van zo'n platform opereren en uitsluitend afhankelijk zijn van de data van dat platform, daar worden gebouwd. Dit stelt domeinen in staat snel te innoveren, waardoor onnodige maatwerkontwikkeling wordt voorkomen.
• Implementeer een gecentraliseerd AI-platform in voor hoogrisico agents en agents die meerdere domeinen overspannen: Voor domeinen zonder zo'n platform, voor agents met hoog risico of voor agents die meerdere systemen overspannen, is een centraal, domeinonafhankelijk AI-platform noodzakelijk. Dit betekent doorgaans een fundamentele cloud AI-hub (bijv. MS Azure AI of AWS Bedrock), een enterprise AI-orkestratieplatform (bijv. Dataiku of Databricks Mosaic AI), en/of een low-code omgeving (bijv. MS Copilot Studio of UiPath). Dit platform moet een handige omgeving bieden waar agents over domeinen heen kunnen worden gebouwd, maar beheerd en bewaakt door centrale risico-, legal- en IT-teams. 

Bij het opschalen van agentic AI zorgt een gebrek aan zichtbare herbruikbare assets er vaak voor dat teams dezelfde fundamentele componenten vanaf nul opnieuw bouwen (pipelines, integratietools, enz.). Deze duplicaties verspillen middelen, veroorzaken inconsistenties en creëren onnodig risico. Door een centraal beheerde bibliotheek van herbruikbare agentic AI-bouwstenen op te zetten, kunnen organisaties de ontwikkeling van nieuwe agents binnen domeinen aanzienlijk versnellen, terwijl risico's worden verminderd en kosten worden verlaagd.

• Identificeer gecentraliseerde activa met hoge waarde: Een centraal team moet gestandaardiseerde componenten identificeren en leveren, zoals getoond in deze bijlage
• Definieer de sourcingstrategie (bouwen versus kopen): De primaire rol van het centrale team is het cureren van dit ecosysteem, in plaats van elk component intern te bouwen: voor veel bouwstenen – vooral de complexere – is het integreren van een derde partij oplossing sneller, veiliger en kosteneffectiever
• Bied een interne ontwikkelaarsmarktplaats: Idealiter zijn de bouwstenen gemakkelijk te vinden via de bestaande servicecatalogus van het bedrijf (of het interne ontwikkelsportaal, API-marktplaats of iets dergelijks), of op het AI-platform(en) afhankelijk van het type. Naadloze ontdekking is de sleutel om ervoor te zorgen dat deze herbruikbare assets daadwerkelijk worden overgenomen door domeinontwikkelaars in plaats van te worden omzeild.

AI-agents brengen aanzienlijke beveiligings-, privacy- en governancerisico's met zich mee, waaronder autonome taakuitvoering, promptinjectie en blootstelling van inloggegevens. Zo benadrukte het brede gebruik van het nieuwe OpenClaw-agentkader eerder dit jaar zowel het potentieel van agents om autonoom te handelen als aanzienlijke beveiligings-, privacy- en governancebedreigingen (zoals het nemen van ongewenste acties, promptinjectie, blootstelling van inloggegevens, enzovoort). Het aanpakken van deze risico's en het waarborgen van naleving van regelgeving, zoals de EU AI-wet, vereist gecentraliseerde zichtbaarheid over gefedereerde agents en geactualiseerde risicokaders.

• Moderniser identiteits- en toegangsbeheer (IAM) voor agents: Traditionele IAM-frameworks, gebouwd rond menselijke gebruikers en statische serviceaccounts, zijn niet geschikt voor autonome agents die privileges kunnen escaleren of taken kunnen delegeren. Organisaties zouden een eersteklas "agent identity"-constructie moeten implementeren met beperkt geautoriseerde, kortdurende referenties die aan specifieke taakcontexten zijn gekoppeld. Dit handhaaft het 'least-privilege'-principe op actieniveau, vereist herautorisatie bij vertrouwensgrenzen en verplicht dat acties met grote impact via door de organisatie goedgekeurde guardrails of 'mens-in-de-lus'-gateways verlopen. Wanneer een agent namens een gebruiker handelt, moet de audittrail zowel de identiteit van de gebruiker als die van de agent vastleggen.
• Breid bedrijfscatalogi uit met AI-metadata: Centrale teams zouden AI-assettracking moeten integreren in bestaande servicecatalogi om risico's te beheren over gefedereerde landschappen zonder de architectuur op te blazen met geïsoleerde "AI-registers". 
• Implementeer observabiliteitsmechanismen: Het verplicht stellen van centrale gateways voor alle LLM- of tool-aanroepen is meestal onrealistisch wanneer AI-agents zich bevinden binnen robuuste domeinplatforms, zoals SAP Joule. In plaats daarvan zouden organisaties het gebruik en gedrag van agents moeten monitoren door:
  • routeringstool-aanroepen via bestaande API-gateways, 
  • AI-specifieke trace-headerstandaarden voor telemetrie vaststellen en telemetrie federeren naar organisatiebrede observability-stacks om uitvoeringstrajecten end-to-end te volgen, 
  • het inzetten van een verplichte gecentraliseerde LLM-gateway voor centrale AI-platforms.

Om domeinoverstijgende AI-use cases succesvol te ondersteunen. Als agents binnen domeinen echter niet gemakkelijk met elkaar kunnen communiceren, is hun waarde beperkt binnen hun silo. Het is belangrijk om te standaardiseren hoe agents contact maken, communiceren en elkaar ontdekken binnen de organisatie.

• Schakel dynamische agentontdekking in via een speciale machinecatalogus: Een aparte, gecentraliseerde agentcatalogus stelt agents in staat om taken dynamisch te vinden en te delegeren aan geautoriseerde peers (bijvoorbeeld: "welke agent kan een factuur verwerken?"). In tegenstelling tot traditionele IT-servicecatalogi moet deze catalogus uitgebreide metadata bevatten (mogelijkheden, gegevenstoegangsrechten, trustniveaus, eigendom, SLA's) en impact analyse van wijzigingen mogelijk maken.
• Vermijd het creëren van een AI-multiversum: Opkomende AI-protocollen (zoals MCP, A2A, ACP en ANP) winnen steeds meer aan populariteit. In plaats van parallelle "schaduw"-netwerken en API-universums te creëren, zouden enterprise architecten deze moeten integreren in gevestigde integratie-backbones. Dit sluit aan bij het kernprincipe van hergebruik van architectuur, wat vertaalt in een evenwichtige aanpak om: 
  • Aanpassen in plaats van herbouwen voor systems-of-record: In plaats van een parallelle MCP-laag te introduceren, bied een generieke OpenAPI-naar-MCP-adapter om te bouwen op bestaande REST-API's en OpenAPI-specificaties. 
  • Vertrouwen op gevestigde standaarden voor domeinoverstijgende communicatie: Agents zouden enterprise API-standaarden moeten gebruiken wanneer ze buiten hun eigen domeingrenzen communiceren, waarbij A2A-protocollen beperkt blijven tot gebruik binnen het eigen domein. Nieuwe protocollen moeten strikt als payloads op de applicatielaag worden behandeld en niet als nieuwe transportmechanismen, zodat ze volledig onderworpen blijven aan gecentraliseerd verkeersbeheer, beveiliging en observatiecontroles.
  • Ervoor zorgen dat bestaande API's AI-klaar zijn: Om bestaande API's opnieuw te gebruiken, moet hun documentatie geschikt zijn voor LLM's. Een effectieve manier om dit te bereiken is door API-lintingtools bij te werken zodat ze uitgebreide en zeer gedetailleerde beschrijvingen van eindpunten, payloads en parameters vereisen.
• Definieer flexibele en gecontroleerde orkestratiepatronen: Meerdere orkestratiemodellen (supervisor/hiërarchisch, gedecentraliseerd, hybride reactief–deliberatief, grafgebaseerd, enz.) kunnen naast elkaar bestaan. De keuze is vaak oplossingsspecifiek, afhankelijk van of beschermingsmaatregelen essentieel zijn of dat fouttolerantie prioriteit heeft. Enterprise-standaarden moeten de keuze van orkestratie sturen om ervoor te zorgen dat AI-oplossingen veilig en betrouwbaar zijn. Basisorkestratie kan bijvoorbeeld worden gebruikt voor laag-risico gebruikssituaties en toezichthoudende orkestratie voor risicovolle scenario's.