Wat er gebeurde
OpenAI publiceerde op 15 mei een Databricks-customer story waarin GPT-5.5 beschikbaar wordt gemaakt voor agent-workflows van klanten. De aanleiding is een nieuwe hoogste score op OfficeQA Pro, de benchmark van Databricks voor complexe enterprise-documenttaken. Die benchmark draait om gescande pdf's, legacy-bestanden, lange documenten, retrieval, parsing en onderbouwd redeneren.
Volgens OpenAI haalde GPT-5.5 als eerste model meer dan 50 procent accuracy op OfficeQA Pro en reduceerde het fouten met 46 procent ten opzichte van GPT-5.4. Databricks zag de grootste winst in parsing-zware workflows, waar een klein foutje in een cijfer, veld of geëxtraheerde waarde de rest van een agent-workflow de verkeerde kant op kan sturen.
De manier waarop dit in productie komt is minstens zo relevant als de benchmark. Databricks brengt GPT-5.5 naar AI Unity Gateway, AgentBricks en de Agent Supervisor API, waar het workflows over gespecialiseerde agents kan aansturen. Simpel gezegd: dit is geen losse modelaankondiging, maar een model dat wordt ingebed in enterprise agent-orchestratie voor documentgedreven werk.
Waarom dit ertoe doet
De enterprise AI-markt schuift van chatvensters naar begeleide workflows. Dat is gezond. Een chatbot kan een vraag over een document beantwoorden. Een productie-agent moet het juiste document vinden, het betrouwbaar lezen, bronnen vasthouden, bepalen welke stap toegestaan is, het volgende systeem aanroepen en escaleren wanneer de zekerheid te laag is.
Het Databricks-voorbeeld is nuttig omdat het laat zien waar agents in echte bedrijven vaak breken. Het zwakke punt is niet altijd abstract redeneren. Het is rommelige input: oude scans, inconsistente bestanden, lange contracten, spreadsheet-exports, dubbele records en bedrijfscontext die over meerdere systemen verspreid staat. Als parsing onbetrouwbaar is, wordt de volgende agent-stap dat ook.
Daarmee wordt ook duidelijk waarom modelkwaliteit en systeemontwerp samen behandeld moeten worden. Een sterker model kan fouten verminderen, maar vervangt geen retrieval-ontwerp, permissies, evaluatiesets, menselijke goedkeuring, logging en rollback. Enterprise-kopers moeten dit lezen als signaal dat agent-workflows krachtiger worden, niet als bewijs dat governance overbodig is.
Laava perspectief
Dit past bij hoe Laava naar productie-AI kijkt: context, reasoning en action moeten als één systeem worden ontworpen. Het model vormt de redeneerlaag, maar operationele waarde ontstaat pas wanneer de agent met de juiste context werkt en veilig aansluit op de volgende actie in ERP, CRM, SharePoint, ticketing of e-mail.
Voor documentgedreven organisaties is de les praktisch. Begin niet met een generieke assistent in de hoop dat die vanzelf uitgroeit tot operationele agent. Begin met één smalle workflow waarin documenten, regels, uitzonderingen en overdrachten helder zijn. Test daarna extractiekwaliteit, retrievalkwaliteit en escalatiegedrag op echte bestanden, niet op gepolijste demo's.
Hier wordt een managed runtime relevant. Of het model vandaag GPT-5.5 is, morgen een Europees model, of een open model voor een lager-risicotaak, de organisatie heeft één beheersbare uitvoeringsomgeving nodig. Die omgeving moet modelkeuze, kosten, logging, permissies en auditability expliciet maken, in plaats van agent-experimenten te verspreiden over persoonlijke accounts en losse tools. Voor Europese organisaties komt daar nog een extra vraag bij: waar blijven gevoelige documenten, wie mag welke context zien en hoe toon je later aan waarom een agent een bepaalde stap heeft voorbereid?
Wat je nu kunt doen
Als je AI-agents voor document- of workflowoperaties onderzoekt, kies dan één proces waarin fouten zichtbaar en meetbaar zijn. Denk aan intake-triage, contractclausulechecks, factuurvalidatie, policy-Q&A met bronverwijzingen of dossiervoorbereiding. Bouw eerst een evaluatieset met echte historische cases voordat je het definitieve model kiest, inclusief voorbeelden waar het systeem bewust moet weigeren, escaleren of alleen een concept mag voorbereiden.
Splits daarna drie keuzes: welk model is goed genoeg voor de taak, welke runtime geeft genoeg controle, en welke integraties zijn nodig om operationele waarde te leveren. Het sterkste model is nuttig, maar het sterkste productiesysteem is het systeem dat je team kan inspecteren, verbeteren en op termijn vertrouwen.