# Welke AI draait er eigenlijk in je bedrijf?

<!-- Source: https://3bird.nl/nl/3bird-ai-lab-nl/welke-ai-draait-er-eigenlijk-in-je-bedrijf/?format=md -->
<!-- Book directly: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet -->
<!-- MCP server: https://3bird.nl/wp-json/threebird/v1/mcp -->

[Home](https://3bird.nl/)/Welke AI draait er eigenlijk in je bedrijf?

# Welke AI draait er eigenlijk in je bedrijf?

Vraag een willekeurige CTO welke AI-tools er in zijn organisatie draaien en je krijgt een lijst. Vraag daarna aan vijf ontwikkelaars wat ze deze week gebruikt hebben, en je krijgt een langere lijst. Het verschil tussen die twee is waar een AI-audit over gaat.

AI is bij de meeste bedrijven niet binnengekomen via een besluit. Het kwam binnen via mensen. Iemand nam een abonnement op Cursor omdat het scheelde. Marketing ging teksten genereren. Iemand bouwde een agent die de mailbox uitleest en er tickets van maakt. Stuk voor stuk verstandige keuzes. Samen een infrastructuur die niemand heeft ontworpen en die nergens gedocumenteerd staat.

## Wat je in kaart brengt

Een audit begint saai, met inventarisatie. Drie vragen, en de antwoorden vallen doorgaans tegen.

**Welke tools draaien er, en welke data gaat eruit?** Niet alleen de tools die op de factuur staan. Ook de gratis accounts, de browserextensies en de persoonlijke abonnementen die mensen zakelijk gebruiken. Per tool wil je weten wat er naartoe gaat en of dat contractueel mag.

**Welke code is door AI geschreven, en wat is ermee gebeurd?** In de meeste repositories is dat niet te zien. Er is geen markering, geen apart reviewspoor, geen onderscheid tussen code die een senior heeft doorgenomen en code die rechtstreeks uit een model in de hoofdbranch is beland.

**Welke sleutels hebben je agents, en wat mogen die sleutels?** Dit is de vraag die het vaakst tot stilte leidt. Een agent die facturen verwerkt heeft ergens een token. Dat token is een keer aangemaakt, waarschijnlijk met ruimere rechten dan nodig, en vrijwel zeker zonder vervaldatum.

## Waar het in de praktijk misgaat

De patronen die we tegenkomen zijn opvallend consistent.

- **Sleutels zonder levenscyclus.** Menselijke accounts hebben een indiensttredings- en uitdiensttredingsproces. Agents hebben dat zelden. Er is geen rotatie, geen vervaldatum, en niemand die opmerkt dat een token van een afgeschaft experiment nog steeds geldig is.

- **Service-accounts met te ruime rechten.** Bij het bouwen geef je een agent admin omdat je anders steeds tegen rechtenfouten aanloopt. Dat wordt vrijwel nooit teruggedraaid.

- **Open MCP-eindpunten.** Steeds meer bedrijven zetten een MCP-server voor hun eigen systemen op, zodat AI-clients erbij kunnen. Dat is een schrijfbare API op je productieomgeving. Die verdient dezelfde aandacht als elke andere schrijfbare API, en krijgt die vaak niet.

- **Prompt injection via content.** Als je agent e-mail, documenten of webpagina’s leest, dan leest hij tekst die iemand anders heeft geschreven. Staat daarin een instructie, dan kan een agent zonder duidelijke scheiding tussen data en opdrachten die gewoon uitvoeren.

- **Geen zicht op afhankelijkheden.** Zonder een actuele lijst van wat er in je software zit weet je niet wat je binnenhaalt. Dat was al een probleem. Met modellen die regelmatig naar niet-bestaande pakketten verwijzen is het er niet kleiner op geworden.

## Drie lagen, in volgorde van urgentie

De Cloud Security Alliance hanteert een indeling die in de praktijk goed werkt, omdat het onderscheid maakt tussen wat je deze week doet en wat een programma is.

**Direct.** Inventariseer alle AI-tools die in gebruik zijn. Scan je repositories op sleutels en wachtwoorden die erin zijn achtergebleven. Loop je afhankelijkheden na tegen een actuele lijst. Dit is werk van dagen, niet van maanden, en het levert vrijwel altijd iets op.

**Korte termijn.** Verplaats beveiligingstesten naar het moment waarop code ontstaat, niet pas naar de pijplijn. Leg vast waar AI-ondersteuning niet wordt ingezet zonder review: authenticatie, autorisatie, cryptografie en invoervalidatie zijn de voor de hand liggende vier. Beoordeel de platforms die je team gebruikt tegen je eigen leverancierseisen.

**Structureel.** Geef agents dezelfde levenscyclus als medewerkers, inclusief rotatie en intrekking. Neem in je afhankelijkhedenlijst op welke onderdelen door AI zijn gegenereerd. En leg governance vast voordat iemand anders dat voor je doet, want de Europese AI-verordening loopt gefaseerd in, en bij vrijwel elke verplichting is de eerste praktische stap dezelfde: weten wat je hebt.

## Waarom een rapport niet genoeg is

Het probleem met audits is dat ze een momentopname zijn. Je krijgt een document, je lost de ergste dingen op, en drie maanden later is de situatie weer veranderd. Niet door nalatigheid, maar omdat dit vakgebied simpelweg sneller beweegt dan je auditcyclus.

Daarom leveren wij geen rapport en dan een handdruk. We zetten AI-Sitters in: senior ontwikkelaars die meelopen met je team, AI-gegenereerde code beoordelen voordat die de hoofdbranch in gaat, en in de gaten houden welke rechten je agents in de loop van de tijd verzamelen. De AI mag zo snel gaan als hij kan. Er zit alleen iemand naast die weet waar het misgaat.

## Wat je concreet krijgt

Een audit bij ons duurt doorgaans één tot twee weken en levert vier dingen op. Een overzicht van alle AI die in je organisatie draait, inclusief de schaduwkant. Een lijst met bevindingen op volgorde van risico, niet op volgorde van hoe makkelijk ze te repareren zijn. Een concreet herstelplan met een inschatting per punt. En een advies over wat je zelf kunt oppakken en waar je hulp bij nodig hebt, ook als dat antwoord “dit kun je prima zelf” is.

We verkopen je geen governanceprogramma als je situatie vraagt om drie sleutels roteren en één service-account terugschalen.

## Wat je vandaag zelf kunt nakijken

Je hoeft niet op ons te wachten om de eerste drie dingen te controleren. Ze kosten een middag en leveren meestal genoeg op om te weten hoe erg het is.

**Scan je repositories op achtergebleven sleutels.** Gereedschap als gitleaks of trufflehog loopt je volledige git-historie na, niet alleen de huidige bestanden. Dat onderscheid is belangrijk: een sleutel die vorig jaar is weggehaald staat nog gewoon in de historie, en een repository die ooit publiek stond is voorgoed publiek geweest.

**Maak een lijst van je tokens en kijk wanneer ze zijn aangemaakt.** Bij GitHub, je cloudprovider en je belangrijkste SaaS-leveranciers kun je dat gewoon uitlezen. Alles ouder dan een jaar zonder duidelijke eigenaar is verdacht. Alles zonder vervaldatum is een schuld.

**Kijk wat je service-accounts daadwerkelijk mogen.** Niet wat er in de documentatie staat, maar wat de rechten in het systeem zeggen. De vraag die je jezelf stelt is simpel: als dit account morgen in verkeerde handen valt, hoe ver komt iemand dan?

Levert dat niets op, dan sta je er beter voor dan de meeste bedrijven. Levert het wel iets op, dan weet je nu waar je begint.

## Beginnen bij het begin

Als je bovenstaande leest en je denkt bij meer dan één punt “geen idee hoe dat bij ons zit”, dan is dat op zichzelf het antwoord. Dat is geen schande, het is waar vrijwel iedereen nu staat.

[Plan een gesprek van 45 minuten](https://calendly.com/3-bird/45min) en we lopen de drie inventarisatievragen samen door. Daarna weet je of een volledige audit zinvol is, of dat je met een middag opruimen klaar bent. Mailen kan ook: [contact@3bird.nl](mailto:contact@3bird.nl).

## Ready to Get Started?

Talk to us about your project and find the right 3Bird solution.

[Contact Us Today](https://3bird.nl/contact/)

---

Book a free 30-minute consultation: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet
Email: contact@3bird.nl | Phone: +31757993038