Google's Deep Research Agent: het krachtigste research-instrument dat je niet blind moet vertrouwen

Een paar maanden terug stuurde een klant me een WhatsApp-bericht: "Dennis, we gebruiken nu ChatGPT Deep Research voor onze marktanalyses. Is dat veilig?" Ik vroeg hem wat voor documenten hij uploadde. "Gewoon, onze strategiedocumenten, kwartaalcijfers, klantanalyses."

Toen wist ik: we hebben een probleem dat groter gaat worden dan de meeste CIO's beseffen.

Google's Gemini Deep Research Agent maakt dat probleem alleen maar scherper. Dit is geen "chatbot met websearch." Het is een managed, asynchrone research-agent die je interne documenten combineert met publieke webbronnen, citeert, grafieken genereert, en een compleet rapport oplevert, terwijl Google de data vastlegt.

En dat laatste is het deel waar de documentatie liever niet te lang bij stilstaat.

Wat Deep Research écht is

Laat ik helder zijn: dit is technisch indrukwekkend. De agent volgt een methodisch patroon, Plan → Multi-source Search → Iterate → Output, dat fundamenteel anders is dan de "vraag-model-antwoord" interacties die we gewend zijn. Hij combineert tot 1.048.576 input tokens, verwerkt tot 3.000 bestanden per prompt met maximaal 3.000 pagina's per bestand, en genereert tot 65.536 output tokens. De kennis-cutoff is januari 2025, de agent draait op Gemini 3.1 Pro, en de API is beschikbaar via de Interactions API.

De agent groundt op vier typen bronnen:

• Google Search, het publieke web, standaard aan
• Enterprise Web Search, websearch met compliance-controls
• Agent Search / Vertex AI Search, je eigen website of documentsets
• Remote MCP servers, externe tools met auth-headers en tool-level restricties

Dat is een indrukwekkende combinatie. De agent kan een PDF van 200 pagina's uploaden, die combineren met vijftig webpagina's, een MCP-server raadplegen voor financiële data, en er een geciteerd rapport van maken met marktpositioneringsmatrices en infographics, gegenereerd door een image-model bovenop de research.

Maar daar begint ook het probleem.

Wat Google niet op de productpagina zet

Deep Research is Preview. Niet "algemeen beschikbaar." Pre-GA. De documentatie waarschuwt expliciet: "Do not upload proprietary, sensitive, or confidential data during Preview."

En de reden daarvoor is niet cosmetisch:

• CMEK ontbreekt, Customer Managed Encryption Keys worden niet ondersteund. Je data wordt versleuteld met Google's sleutels, niet met die van jou.
• VPC Service Controls ontbreken, geen netwerkisolatie. Data kan grensoverschrijdend bewegen zonder dat je het weet.
• Access Transparency ontbreekt, je kunt niet auditen of Google-medewerkers je data hebben ingezien.
• Multi-region data residency is "under evaluation", oftewel: er is geen garantie waar je data fysiek staat.
• Impliciete caching staat verplicht aan en kan niet worden uitgezet. Cached data valt buiten je controle.
• Data retentie is verplicht: 7 dagen standaard, en bij Google Search grounding 3 dagen, deze kan niet worden uitgeschakeld. Voor zero retention moet je Enterprise Web Search gebruiken.

De architectuurboodschap is helder: je geeft Google niet alleen een prompt, maar documenten, spreadsheets, strategische analyses, klantgegevens, en die liggen minimaal 3 tot 7 dagen in Google's infrastructuur, versleuteld met hún sleutels, zonder dat je kunt controleren wie er toegang toe heeft gehad.

Dat is voor BIO2, NIS2, ISO 27001, GDPR of sectorale datalocatie-eisen niet een nice-to-have die later wel komt. Dat is een harde gating factor.

Het compromise scenario

Stel: een beleidsmedewerker bij een ministerie uploadt een vertrouwelijk beleidsstuk naar Deep Research met de vraag "analyseer de haalbaarheid van dit voorstel, vergelijk met internationale benchmarks."

De agent doorzoekt het web, combineert de interne analyse met publieke data, en levert een messcherp rapport met citaties, grafieken en aanbevelingen.

Wat er dan gebeurt:

1. Het document, de prompt, en de output liggen minimaal 3 dagen bij Google, versleuteld met Google's sleutels
2. Er is geen audit-log of Google's eigen toegang tot die data (geen AXT)
3. De data is niet geïsoleerd per regio of netwerksegment (geen VPC-SC)
4. Impliciete caching slaat data op die jij niet kunt wissen
5. Als Google morgen een dagvaarding krijgt onder de CLOUD Act, liggen jouw strategische overheidsanalyses daar

En ja, dit is Preview. De controls komen "later." Maar wie garandeert dat een medewerker niet vandaag al gevoelige documenten uploadt omdat de productiviteitswinst té verleidelijk is?

De vier veiligheidszones die je nú moet beheersen

De veiligheidsrisico's zitten in vier concrete zones, en Google waarschuwt er zelf voor:

1. Prompt injection via documenten. De PDF waarschuwt expliciet dat geüploade bestanden verborgen tekst kunnen bevatten die de agent probeert te manipuleren. Een kwaadwillende PDF kan instructies bevatten die de agent aanzet tot het lekken van data of het negeren van veiligheidsregels. Met toegang tot web search én MCP servers is de impact groter dan bij een losse chatbot.

2. Data-exfiltratie door gemengde grounding. Het combineren van gevoelige interne data met publieke webtoegang creëert een exfiltratiekanaal. De agent kan onbedoeld interne context verwerken in zoekopdrachten aan publieke bronnen. Google's eigen documentatie zegt: "use caution when summarizing sensitive internal data while granting web access."

3. MCP-server supply-chain risico. Remote MCP servers zijn krachtig, maar vormen een supply-chain en authorization boundary. Gebruik alleen allowlisted servers met mTLS of sterke OAuth2/OIDC, per-tool allowlists, egress policies, audit logging en tenant-isolatie. De documentatie noemt allowed_tools als parameter, gebruik die altijd.

4. Citation trust. "Verify all citations despite enterprise-grade filtering." Dat staat in Google's eigen best practices. Voor C-level besluitvorming moet je citations behandelen als evidence candidates, niet als bewezen feiten zonder validatie.

Waarom je dit tóch gaat gebruiken

Hier komt het ongemakkelijke deel: de productiviteitswinst is te groot om te negeren.

Een analist die normaal twee weken doet over een concurrentieanalyse krijgt in twee uur een geciteerd rapport met visuals. Geen 10% verbetering, een orde van grootte. Het Plan-Search-Iterate-Output-patroon past precies bij beleidsanalyse, marktverkenning, vendor due diligence, juridische quickscans en technology scouting.

De juiste vraag is niet "gebruiken of niet?" De juiste vraag is: hoe classificeer je de inzet, en welke controls zet je eromheen?

De governance-classificatie die je nodig hebt

Voor gereguleerde organisaties classificeer ik Deep Research als "AI-assisted decision preparation," niet als "automated decision-making." Dat onderscheid is belangrijk voor de AI Act, GDPR, interne mandaten en auditability.

Praktisch betekent dat een heldere geschiktheidsmatrix:

• Publieke markt- en technologieverkenning: Hoog geschikt, mits Enterprise Web Search. Geen bijzondere persoonsgegevens.
• Vendor due diligence: Hoog geschikt, met bronvalidatie en menselijke review.
• Beleidsvoorbereiding: Middel-hoog, zolang er geen gevoelige persoonsgegevens in de input zitten.
• Interne kenniszoektocht: Middel, alleen met gesaneerde documentsets.
• Compliance research: Middel, juridische validatie verplicht, nooit als enige bron.
• Automatische besluitvorming: Laag, niet geschikt.
• Hooggevoelige data-analyse: Laag, wachten op GA met CMEK, VPC-SC en data residency.

En dan de harde grens: geen hooggevoelige data met publieke webgrounding combineren. Splits interne en externe research flows, en maak data-classificatie leidend voor toolkeuze.

De referentiearchitectuur voor governed research

Hoe ziet een veilige inzet eruit? Als een gelaagde architectuur met controles op elk niveau:

Policy Decision Point. Classificeer elke onderzoeksvraag op datagevoeligheid, doelbinding, juridische basis, broncategorie en toegestane tools, vóórdat de prompt naar Google gaat.

Tool Allowlist Layer. Standaard: deny all, allow by policy. Expliciet aangeven of Google Search, Enterprise Web Search, Agent Search of MCP beschikbaar is. Default-tools uitzetten is geen optie, het is een vereiste.

Evidence Store. Leg vast: het final report, alle citations, de prompt, de toolconfiguratie, het interaction-id, het kostenlabel, en de reviewstatus. Want zodra de 7 dagen voorbij zijn, is de data bij Google verdwenen.

Human Review Gate. Verplicht voor C-level memo's, beleidsstukken, compliance claims, juridische conclusies en externe publicatie. Geen rapport verlaat de organisatie zonder menselijke validatie.

FinOps & Observability. Gebruik het automatische is_deep_research billing label voor kostenanalyse. Geen losse AI-tool, een governed research-capability met inzicht in token-kosten, search-kosten, en ROI per use case.

Deep Research vs. klassieke RAG

Ik zie veel organisaties denken dat Deep Research "gewoon RAG met websearch" is. Dat is het niet.

Klassieke RAG beantwoordt: "Wat staat er in mijn corpus?" Deep Research beantwoordt: "Hoe onderzoek ik een complexe vraag met meerdere bronnen, iteratie en synthese?" Het is geen vervanging van RAG, het is de volgende laag erboven.

De implicatie voor architectuur is groot: RAG is een retrieval-laag, Deep Research is een research orchestration-laag. Je hebt ze allebei nodig, maar voor verschillende use cases. En Deep Research heeft meer governance nodig, niet minder, juist omdat de tool-toegang breder is en de output minder gestructureerd.

Wat DjimIT hiermee doet

Voor ons is Deep Research geen product om te verkopen. Het is een showcase van waar agentic AI naartoe beweegt, en een kans om te laten zien hoe je dat veilig maakt.

Drie proposities:

• Secure Deep Research Workbench, een referentie-implementatie met prompt templates, policy gateway, bronvalidatie, logging, DPIA-pack en security baseline. Voor organisaties die wél willen, maar niet blind.
• AI Research Governance Assessment, beoordeel of een organisatie Deep Research, ChatGPT Deep Research, Perplexity Enterprise, NotebookLM of interne RAG-tools verantwoord inzet. Output: risk register, control matrix, maturity score, target architecture.
• Agentic Knowledge Operations, positioneer Deep Research als research-capability binnen een bredere agentic stack met Agent Search, MCP, GraphRAG, evidence stores, human review en audit trails.

De commerciële invalshoek is niet "gebruik dit product." Het is: "we laten je zien hoe je dit veilig doet, en de organisaties die het zonder governance doen, lopen risico."

Conclusie

Google's Deep Research Agent is een strategisch signaal dat verder reikt dan "weer een nieuw model." Het is de operationalisering van research agents als managed cloud capability: identity, tools, grounding, streaming, cost labels, search, MCP en document understanding in één managed patroon.

Maar de enterprise readiness is beperkt: Preview-status, verplichte caching, verplichte retentie, single-turn gedrag, ontbrekende CMEK/VPC-SC, geen structured output, en geen harde data residency. Voor overheidsklanten is het nu alleen geschikt voor gecontroleerde pilots met publieke of laaggevoelige data.

De beste invalshoek is daarom niet "dit meteen breed uitrollen," maar "dit gecontroleerd instrumenteren als voorbeeld van governed agentic research." Gebruik het als showcase: agentic AI met executiekracht, maar onder governance, auditability en Zero Trust.

Want het alternatief, medewerkers die wél gebruiken zonder controls, is niet hypothetisch. Het gebeurt nu al.

---

Dit artikel is gebaseerd op de Google Cloud documentatie van de Gemini Deep Research Agent (Preview, 29 mei 2026), de Developer's Guide van Eric Dong (28 mei 2026), en de officiële agent card. De security-analyse en governance-aanbevelingen zijn gebaseerd op de technische specificaties en beperkingen zoals door Google zelf gerapporteerd.