# Using AI safely: What it may see, and what it may do. URL: https://goudbeek.com/en/security Language: en Last updated: 2026-09-24 Provider: Goudbeek — Almere, the Netherlands — samgoudbeek2007@gmail.com > Using AI safely: Goudbeek decides up front what an AI system may see and do, with a person behind every action that matters. Also as a review of AI you run. 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](https://goudbeek.com/en/solutions/agents) and [chatbots](https://goudbeek.com/en/solutions/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. ## Six things that are decided before anything runs. ### 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. ### A line between drafting and doing 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. ### Every answer carries its source 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. ### It is allowed to say it does not know 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. ### Untrusted text stays untrusted 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. ### There is a record 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. ## Questions about using AI safely Straight answers, including the ones about what we do not promise. ### Can an AI agent be tricked into doing something it should not? 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. ### Is Goudbeek SOC 2 or ISO 27001 certified? No, Goudbeek itself holds no SOC 2 or ISO 27001 certification. The SOC 2, ISO 27001 and PCI DSS marks on the [hosting page](https://goudbeek.com/en/hosting) 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. ### When do you settle the security of an AI system? 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](https://goudbeek.com/en/solutions). ### What data does the AI get access to? 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. ### How do you handle prompt injection? 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. ### Can we see what the AI did and why? 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. ### What is an AI security review? 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. ### Is the review a penetration test or a certification? 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. ## Written down before it is built. 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 review](https://goudbeek.com/en/contact) ## A review of the AI you already have. The 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 - A map of what the system can reach — every document store, system and credential it holds, and which of them the job actually needs. - The list of actions it can take without a person, separated into the ones that are fine there and the ones that are not. - Where its answers come from, and whether anyone could trace one back if a customer disputed it. - What is recorded when it runs, and whether that would be enough to work out what happened after an incident. - A ranked list of changes: what to fix this week, what to fix before it grows, and what is fine as it is. Who it is for Teams already running an AI agent, chatbot or automation that touches real data, who have never had anyone ask these questions about it out loud. What it is not It is not a penetration test, and it is not 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. [Ask about a review](https://goudbeek.com/en/contact) ## The floor underneath it. 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 platform](https://goudbeek.com/en/hosting) ## Three notes on the same question. From the [knowledge base](https://goudbeek.com/en/notes): 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](https://goudbeek.com/en/solutions/agents) and [chatbots that answer from your own data](https://goudbeek.com/en/solutions/chatbots). ### [What an AI agent is allowed to do is a design decision, not a setting](https://goudbeek.com/en/notes/what-an-agent-is-allowed-to-do) The 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. 2 Sept 2026 4 min read ### [The EU AI Act, for a business with one chatbot](https://goudbeek.com/en/notes/eu-ai-act-for-one-chatbot) You 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. 18 Aug 2026 5 min read ### [Prompt injection, explained without the hype](https://goudbeek.com/en/notes/prompt-injection-without-the-hype) The 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. 29 Jul 2026 4 min read ## Want to know what yours would be allowed to do? 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](https://goudbeek.com/en/contact)