Secure AI starts with knowing where your data goes

WebParam perspective | October 2026

An employee pastes a customer email into an AI assistant to draft a reply. A finance team tests a tool against invoices. An operations team connects a model to a shared folder so it can answer questions faster.

Each idea could save time. Each also changes who or what can see the information, how it moves, and who is responsible when the output is wrong.

South Africa is observing Cybersecurity Awareness Month in October 2026. The Cabinet's statement calls for digital safety and resilience; it does not measure demand for AI or endorse a particular technology. For businesses, the useful connection is a practical one: secure AI adoption begins before a model is selected. It begins with the data and the workflow. [1]

Before testing an AI use case, identify the information the tool would receive. Is it public marketing copy, internal operational data, customer records, contracts, or credentials? Who owns it, who may access it, and what may be sent to an external provider?

Map the whole route, not only the prompt. A document may be uploaded, broken into searchable fragments, stored in logs, sent to a model, returned as an answer and copied into another system. Each step creates a decision about access, retention and deletion. If the team cannot draw that route, it is too early to approve the integration.

This is especially important when an assistant is connected to internal systems. A user who can ask a question should not automatically gain access to every document the connector can retrieve. Permissions need to follow the person and the task, with tests for what an ordinary user cannot see.

A useful first pilot has one workflow, one accountable owner and a limited set of approved data. Consider an internal support team that wants to summarise incoming enquiries. Start with a defined queue and remove information the tool does not need. Let the system suggest a summary or routing decision; keep a person responsible for reviewing uncertain cases and sending the final response.

Agree on the boundaries before switching it on:

• Allowed inputs: Which documents and fields can the system process?
• Access: Which staff and services can use it, and with what permissions?
• Provider behaviour: Where is data processed, how long is it retained, and is it used to improve a model? Verify the actual service terms and configuration.
• Human review: Which outputs need approval, and what happens when the model is unsure or wrong?
• Records and response: What is logged, who checks the logs, and how can the team stop or roll back the workflow?

These are design decisions, not a claim that one deployment model is automatically safe. A hosted service, a private deployment and an internal build each need scrutiny against the information and task involved.

An AI assistant may read a web page, email or document to complete a legitimate request. That material can contain instructions aimed at the assistant rather than facts for the employee. The risk is called prompt injection. OWASP also identifies sensitive information disclosure among the major risks for applications built on large language models. [2]

The practical response is to limit what the assistant can reach and do. Give a retrieval tool only the documents needed for the task. Separate source content from operational instructions. Require approval before an assistant sends a message, changes a record or takes another consequential action. Test with misleading documents and unusual requests, including cases designed to coax the system into revealing data it should not disclose.

Do not assume a prompt telling the model to be careful is a substitute for permissions and system controls.

A pilot is not ready to expand merely because its demonstrations look convincing. Measure how often it completes the intended task, how often staff must correct it, whether it exposes information outside the user's access, and whether its logs make a bad outcome traceable. Test ordinary cases and the exceptions that occur in the real workflow.

Define a stop condition in advance. If the tool repeatedly misroutes sensitive enquiries, produces answers without reliable source support or adds more review work than it removes, revise the design before expanding. The goal is an operational improvement that the business can explain and control.

NIST's generative AI profile is a useful reference for organisations structuring this work: govern the use case, map its context, measure the risks and manage them over time. It is a framework for decisions, not a certificate that a particular system is secure. [3]

At WebParam, we would begin with the workflow, systems and data the organisation already has. A readiness assessment can reveal whether the needed information is usable, whether access is properly scoped, where integrations are required and where people must stay involved. From there, a business can choose a limited pilot with clear measures and controls.

Cybersecurity Awareness Month is a useful prompt to ask a concrete question: Can we explain what this AI system can access, what it can do, and how we would detect and correct a mistake? If the answer is unclear, that is the next piece of work. It is also the right place to start.

1. South African Government, Cabinet statement of 23 September 2026, published 29 September 2026. The October observance is stated under “Cybersecurity Month.”
2. OWASP Top 10 for LLM Applications 2025, including prompt injection and sensitive information disclosure.
3. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.