Least access, by default
It gets the documents and systems the job needs, and nothing beyond them. Access is granted per source rather than per system, so a chatbot that answers questions about delivery has no route to your payroll.
Using AI safely means deciding up front what an AI system may see, what it may do on its own and what always waits for a person. Goudbeek in Almere builds AI agents and chatbots to those rules, and reviews AI you already run against the same six points.
Most of the risk in an AI system is not the model. It is what you let it reach, and what you let it do without anyone watching. Every build here starts from those two questions, and the answers are written down before a line of it ships.
It gets the documents and systems the job needs, and nothing beyond them. Access is granted per source rather than per system, so a chatbot that answers questions about delivery has no route to your payroll.
Reading, searching and drafting cost little if they go wrong. Sending, paying, deleting and changing records can cost a lot. Anything with consequences sits behind an approval until you decide otherwise.
When it answers from your material it says which document and which passage it used. An answer nobody can trace is an answer nobody can check, and one you cannot defend to a customer.
A system that always produces something will sooner or later produce something wrong with a straight face. These are built to refuse and hand over at the edge of what they know, which is the behaviour people actually want there.
Anything arriving from outside — a customer email, a web page, an uploaded PDF — is treated as data, never as instruction. A language model cannot make that separation watertight, so we limit what such text can do: the system can only reach what the job needs, and anything with consequences waits for a person by default.
What it was asked, what it read, what it did and who approved it. Not for the brochure: it is how you work out what actually happened on the day something looks wrong.
Straight answers, including the ones about what we do not promise.
Yes, an AI agent can be tricked. No AI system is immune, and anyone who tells you theirs is has something to sell. The useful question is what it can reach on the day it is fooled. That is why it only gets access to the sources the job needs, and why anything with consequences — sending, paying, deleting, changing records — sits behind a human approval by default.
No, Goudbeek itself holds no SOC 2 or ISO 27001 certification. The SOC 2, ISO 27001 and PCI DSS marks on the hosting page belong to the platform underneath. They say the infrastructure is independently audited. They say nothing about whether your AI agent is allowed to send an email on its own. That part is ours: the access model, the approval line and the record, agreed before the build starts.
The security of an AI system is settled at the intake, not at the end. Access, approvals and logging are decided before anything is built, because bolting them on afterwards means rebuilding the system around them. If a build would need access we are not comfortable granting, that is a conversation before the quote, not after. What is agreed is written down and stays yours to change. That holds for every one of our AI solutions for businesses.
The AI only gets access to the documents and systems the job needs, and nothing beyond them. Access is granted per source rather than per system: a chatbot that answers questions about delivery has no route to your payroll. Which sources those are is decided together before the build and written into the agreement.
To guard against prompt injection, we treat anything arriving from outside the system — a customer email, a fetched web page, an uploaded PDF — as data, never as instruction. Nobody can fully rule out that a model reads such text as a command anyway. That is why the system also gets least access and an approval on actions with consequences: a successful injection then reaches far less than it otherwise would.
Yes, you can see what the AI did and why. What it was asked, what it read, what it did and who approved it are recorded. Answers drawn from your own material name the document and the passage they came from. An answer nobody can trace is an answer nobody can check — and one you cannot defend to a customer on the day it is disputed.
An AI security review is a review of an AI agent, chatbot or automation that is already running, whether somebody else built it or you put it together yourself. We hold your setup against the same six points we build with, and hand back what it can reach, what it can do without a person, where its answers come from, what is recorded, and a ranked list of what to change first.
No, the AI security review is neither a penetration test nor a certification against a standard — we are not an auditor and will not pretend to be one. It is an engineering review by the person who builds these systems, written so you can act on it. It is meant for teams already running AI that touches real data, who have never had anyone ask these questions out loud.

What a system may reach, what it may do alone and what always waits for a person is decided on paper first, and stays yours to change.
Ask for a reviewThe six above are how we build. They are also a checklist you can hold an existing system against — one somebody else built, or one you put together yourself. That is the review: we go through your setup against the same questions and hand back what it can reach, what it can do unwatched, what is recorded, and what we would change first.
What you get
The controls above are about the system we build. The ground it stands on — HTTPS everywhere, always-on DDoS protection, an independently audited platform — is the hosting side, and it has its own page.
See the platformFrom the knowledge base: what an agent may do, what the EU AI Act asks of a business with one chatbot, and prompt injection without the hype. To see these rules in a working system, read about AI agents for customer service and chatbots that answer from your own data.
AI securityThe interesting question was never how clever the model is. It is what the thing can reach on a bad day, and who signed off on that.
RulesYou do not need to read the whole AI Act. You need to know which risk category your system falls in, and that it follows from what the system does rather than what it is built with.
AI securityThe attack is old news in a new costume: text arrives from outside and the system cannot tell instruction from content. What matters is what it reaches once it works.
Describe the job and the systems it would touch. You get a straight read on what it should be allowed to reach, what has to stay behind a person, and whether it is worth building at all.
Start the conversation