{"id":7583,"date":"2025-06-09T14:10:22","date_gmt":"2025-06-09T12:10:22","guid":{"rendered":"https:\/\/blog.bart.sk\/en\/?p=7583"},"modified":"2025-08-06T08:53:46","modified_gmt":"2025-08-06T06:53:46","slug":"when-a-chatbot-says-too-much-rules-for-safe-ai","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/when-a-chatbot-says-too-much-rules-for-safe-ai\/","title":{"rendered":"When a Chatbot Says Too Much: Rules for Safe AI"},"content":{"rendered":"\n

AI chatbots and assistants are now helping answer customer questions, summarize data, and support administrators. They\u2019re always available, faster than any human, and\u2014if configured properly\u2014surprisingly accurate. But with this convenience comes a pressing question: What happens when AI says more than it should\u2014to your clients, your team, or even the entire world?<\/strong><\/p>\n\n\n\n

This isn\u2019t a hypothetical concern. In 2023, a student cleverly tricked Microsoft\u2019s Bing AI chatbot into revealing internal system rules that were meant to stay hidden.<\/strong> Due to a misconfiguration, even regular users could access this sensitive information.<\/p>\n\n\n\n

Cases like this demonstrate that AI is powerful\u2014but still lacks context and risk awareness<\/strong>. That\u2019s why the conversation around AI safety now includes not just companies but regulators too.<\/p>\n\n\n\n

As of August 2024, the EU\u2019s AI Act has come into force\u2014the first comprehensive law governing artificial intelligence in the European Union. Its goal is to differentiate between high- and low-risk AI use cases<\/strong> and to establish clear rules where AI could impact users\u2019 privacy, health, or safety.<\/strong><\/p>\n\n\n\n

\n

Today, it\u2019s not enough for developers and companies to simply \u201chave AI.\u201d It must be designed to comply with the AI Act and remain useful, trustworthy, and safe for all users.<\/strong><\/p>\n<\/blockquote>\n\n\n\n

In the following section, we\u2019ll explore the most common mistakes companies make when implementing AI\u2014and the practical rules that help prevent them.<\/p>\n\n\n\n

How We Do It in Practice:<\/strong><\/h2>\n\n\n\n

1. AI Never Gets More Than It Actually Needs<\/strong><\/h3>\n\n\n\n

We design every AI solution with the principle of \u201cnarrow context\u201d in mind. That means the model receives only the specific data it needs to respond accurately<\/strong>. It is never directly connected to a live database or production system. All inputs are preprocessed, filtered, and structured<\/strong> so only relevant information reaches the model. This significantly reduces the risk of misinterpretation, unintentional data exposure, or contextual errors.<\/strong><\/p>\n\n\n\n

This approach is essential in projects involving sensitive data\u2014like medical records\u2014but we apply it even when working with public data sets.<\/p>\n\n\n\n

\n\n\n\n

2. Data Stays in the EU and Is Never Used for Further Training<\/strong><\/h3>\n\n\n\n

In any project involving personal or business data, we need to know exactly where the data is stored and what guarantees the infrastructure provides. For example, with the Crossuite medical system based in Belgium, we use AWS hosting in Frankfurt, Germany\u2014fully complying with the AI Act requirements for high-risk systems. These include provisions that personal data collected within the EU must be processed primarily within the EU<\/strong> and always in line with EU regulations.<\/p>\n\n\n\n

Amazon\u2019s terms also explicitly guarantee that our input data is not stored, evaluated, or used to train the model further<\/strong>. This is especially critical in fields like healthcare, where any overlap between user data and model training is strictly prohibited.<\/p>\n\n\n\n

Our responsibility is not only technical, but legal\u2014clients must know that what AI \u201csees\u201d stays between them and the model<\/strong>. No one else\u2014not now, and not in the future\u2014should have access to that data.<\/p>\n\n\n\n

\n\n\n\n

3. Secure Inputs Are the Foundation of Safe Outputs<\/strong><\/h3>\n\n\n\n

AI safety isn\u2019t just about what data the model receives, but how it\u2019s guided to respond. In every project, we design prompts to ensure the model sticks to relevant information, stays on topic, and provides clear, predictable answers.<\/strong><\/p>\n\n\n\n

We use predefined templates that define what information the AI can access, the desired tone of the response, and how it should react to uncertainty. We also monitor whether it stays within these constraints. This approach\u2014known as prompt engineering\u2014turns AI into a trusted tool, not an unpredictable experiment.<\/strong><\/p>\n\n\n\n

\n\n\n\n

4. If Needed, We Anonymize Data Before AI Even Sees It<\/strong><\/h3>\n\n\n\n

Not every application handles sensitive data\u2014but any app might one day. Dejmark, for example, uses AI<\/a> to simplify repeat purchases for their sales team. A photo of an old order, receipt, or ERP screenshot is enough for the AI to identify products, quantities, and volumes, and create a new cart. Currently, this process doesn\u2019t handle personal data\u2014but in the future, it might process invoices or delivery notes, which could include names, addresses, or email contacts.<\/p>\n\n\n\n

That\u2019s why we built anonymization into the solution from day one\u2014using regex filters or preprocessing at the application layer. The model never sees raw input, only a clean extract without identifiers.<\/strong><\/p>\n\n\n\n

\n\n\n\n

5. Every Output Is Traceable, Explainable, and Adjustable<\/strong><\/h3>\n\n\n\n

Transparency builds trust. For every AI implementation, we create mechanisms to audit outputs<\/strong>. Our goal is to always be able to trace what was asked, how the model responded, and why<\/strong>\u2014so the results can be verified and explained if needed.<\/p>\n\n\n\n

This is especially important in healthcare: if there\u2019s a discrepancy in data summaries, we need to understand what the model based its response on. In chatbot applications, we check whether the model stays within its role, and if not, we can retrain it, adjust the prompt, or refine the input handling.<\/p>\n\n\n\n

Every AI deployment goes through a two-step testing process: internal review by our developers and final validation by the client before going live.<\/strong><\/p>\n\n\n\n

This allows us to build AI that\u2019s not only functional\u2014but defensible.<\/strong><\/p>\n\n\n\n

\n\n\n\n

6. Trusted Models, Clear Rules, Ongoing Oversight<\/strong><\/h3>\n\n\n\n

AI safety begins with choosing the right model and provider.<\/strong> In our projects, we prioritize partners who offer proven technology, transparent policies, and strong data protection\u2014like OpenAI via Azure, Google Vertex AI, AWS Bedrock, or self-hosted solutions. Their infrastructure includes encryption, access control, and regular audits.<\/strong><\/p>\n\n\n\n

On top of this infrastructure, we define strict usage rules\u2014what data the model can process, its limits, and fallback instructions for uncertainty.<\/strong> Every solution undergoes internal testing and client validation. Regular security audits help us adapt these rules as technology, regulations, or data types evolve\u2014so our AI remains safe and reliable long term.<\/strong><\/p>\n\n\n\n

AI Has Limits\u2014And We Set Them So You Can Trust It<\/strong><\/h2>\n\n\n\n
\n

The biggest risk with AI isn\u2019t the technology\u2014it\u2019s letting it operate without clear boundaries.<\/p>\n<\/blockquote>\n\n\n\n

At bart.sk, we design AI solutions to be useful, trustworthy, and\u2014above all\u2014safe. We respect data sensitivity, legal obligations, and user needs. Trust isn\u2019t something you leave to the model. It has to be built into the architecture from day one.<\/strong><\/p>\n\n\n\n

\n\n\n\n

Sources<\/strong><\/h3>\n\n\n\n