Using AI safely

1. AI chat

AI chat is the simplest and most popular way to use large language models: an interactive conversational model running in the provider's cloud that you talk to in a question-and-answer mode through a browser or an app. You type a message (a so-called prompt), the model replies, you follow up — and round it goes. It's worth stating up front what chat is NOT: it isn't an agent that clicks around your system on its own, sends emails, or operates on your files. Beyond the conversation itself, the model takes no autonomous actions. All its "power" is confined to the chat window. (Note: some providers now bolt extras onto chat — web search, plugins, or "agentic" modes — but these are add-ons built on top of plain chat, not its default behavior.)

The mechanics are simple but crucial for assessing risk: everything you type into a prompt — including pasted documents, code snippets, customer data, or system dumps — is sent to the provider's servers and processed there. The model does not run locally on your computer; your computer merely displays the interface. This means that the decision of "what to paste into the chat" is, in practice, a decision about "what to send to an outside company." For a private individual this is usually acceptable; for a small business handling customer data, contracts, or trade secrets, it becomes a deliberate choice that should be thought through (and where personal data is involved, it also becomes a question of GDPR and of where the servers physically sit).

Where that data goes next and how long it lives depends on the specific provider, the plan you've chosen, and your account settings. Depending on these factors, conversations may (but need not) be used to train future versions of the model, and some of them are reviewed by humans as part of moderation and abuse control. Business and enterprise plans usually disable training on your data by default and provide additional contractual guarantees, whereas free accounts tend to be more "open" in this respect. Bear in mind, though, that "no training" is not the same as "no storage" — even when data isn't used for training, conversations are usually still logged for some time (abuse, legal requirements). This is neither a conspiracy theory nor a reason to panic — it's the normal operating model of a cloud service, one you simply need to understand and adapt your habits to.

From a security standpoint, then, treat AI chat like a highly competent but external consultant reached over the internet: excellent for writing, learning, translation, and brainstorming, but not the place for passwords, API keys, customers' personal data, or confidential documents that you wouldn't send in an ordinary email to a company you don't know. On top of that comes a second pitfall, independent of privacy: the model can assert, in a confident tone, things that are simply untrue (hallucinations) — and this applies to answers that come with cited "sources" too, which are sometimes fabricated or irrelevant. That's why chat answers are worth verifying wherever facts matter, not just the form they take.

2. AI agent

An AI agent isn't just another chatbot—it's a language model (LLM) embedded in an action loop. Instead of merely answering questions, an agent first plans out the steps, then reaches for tools—a browser, a terminal, APIs, files, a code interpreter—carries out the task in stages, checks the result, and decides on its next move. The key word is "action": an agent doesn't just say what to do, it actually does it on your behalf. That shifts it from the role of advisor to the role of doer.

The difference from an ordinary chat is fundamental, and it shows up most clearly in the side effects. A chat generates text—the worst it can leave you with is bad advice, which you judge for yourself before acting on it. An agent operates on your environment: it can create a file, send an email, change a record in a database, run a script, commit code. The human stops being the intermediary between the model's idea and its execution—and it was precisely that intermediary who used to catch the mistakes. That's why, with an agent, what matters is not only the quality of the answers but exactly what it has access to and what it can irreversibly change.

Technically, an agent runs in a repeating cycle: it receives a goal, breaks it into steps, picks a tool, runs it, reads the result (the contents of a page, the contents of a file, an error code, an API response), and plans onward on that basis—until it judges the task finished or gets stuck. This ability to read the outside world is its strength, but it has two dark sides. First: the model treats whatever content it encounters as context, and a doctored page, file, or email can contain hidden commands (prompt injection) that the agent will treat as an instruction from you—and it will use its own tools (email, APIs, the network) to spirit your data out. Data from the internet and from third parties is untrusted, and an agent doesn't distinguish this by default. Second: in a multi-step loop, errors accumulate—a slip in one step drags the following ones down with it, and an agent can get stuck in a loop or "invent" a nonexistent fact just to close out the task.

From the standpoint of privacy and control over your data, an agent is at once the greatest lever and the greatest risk. To do meaningful work, it has to be granted access to some slice of your world: a repository, a mailbox, a drive, a SaaS account. Every such access widens the attack surface and is a potential leak channel. For an individual and for a small business, this isn't an argument for giving up on agents—it's an argument for letting them in deliberately: granting the minimum of permissions (least-privilege), running them in a sandbox or on a copy, and leaving all irreversible actions (sending, deletion, payment, publication) for a human to approve (human-in-the-loop). An agent is meant to do the boring work for you, not to make decisions on your behalf that can't be undone.

Which agent for what

3. Your own AI model on a PC + agent

A local AI model is simply a language model run on your own hardware — a laptop, a workstation, or a server at your company — instead of in a provider's cloud. The entire difference comes down to where the processing physically takes place. When you query a cloud chat, your text (and often the files you upload) travels to someone else's servers. With a local model, the prompt, the response, and the documents stay on your machine. Nothing leaves your premises unless you set it up to.

There are several reasons to do this locally, and they are concrete ones. Privacy and control over your data — sensitive client data, code, contracts, or notes never reach any third party, which simplifies (though does not by itself settle) the questions of GDPR and trade-secret protection. Offline operation — the model runs without an internet connection, so it holds up in an isolated environment or wherever the link is unreliable. No per-token fees — you pay once for the hardware and the electricity, and after that you generate as much as you like, with no meter ticking on every query. And full control: you pick the model and its version yourself, nothing changes on you overnight, there are no abrupt shifts in provider policy, no prompt censorship, and no vendor lock-in.

No sugar-coating: this is not a free lunch. The models you can fit on a typical PC reason less capably and use tools less well than the best cloud models — you have to match your tasks to them realistically. You also need a decent GPU or plenty of RAM, and the upkeep (updates, configuration, the electricity bill) falls on you. Bear in mind, too, that local does not automatically mean secure — the model server and the files you download demand the same hygiene as any other service. For many use cases, though — summarizing documents, help with code, classification, rough drafting of text — a local model is already more than sufficient, and your data stays entirely with you.

An agent on a local model

A local model is not just a chat window — you can build an agent on top of it, that is, an AI that carries out tasks on its own and uses tools. The simplest route is a coding plugin: Cline or Continue in VS Code pointed at a local Ollama endpoint — the assistant reads and writes code without sending your repository to the cloud. For process automation, n8n fits the bill, with an AI step wired to the local endpoint (e.g. "read the email, classify it, save it to the database"). Open WebUI can hand the model tools and search, and if you are building something of your own, frameworks like LangChain or CrewAI run happily against a local OpenAI-compatible API — from their point of view your Ollama looks like any ordinary provider. You do have to keep your expectations in check, though: smaller local models reason less well and are noticeably worse at using tools (function calls) than top-tier cloud models, so the agent tends to be less reliable and needs simpler, well-described tasks. On top of that comes the hardware — meaningful tool use and a longer context call for a decent GPU and plenty of RAM/VRAM. And one more thing from a security standpoint: an agent is a model that genuinely reaches into your files, network, and commands — keep its permissions narrow and the local endpoint on localhost or behind authentication, because otherwise you are opening a back door into your own network.

4. Hygiene with commercial AI models

When you use a commercial, cloud-based AI model — ChatGPT, Claude, Gemini, or any other one accessible through a browser or an API — you have to accept one premise: everything you type into the chat window leaves your computer and lands on someone else's servers. This is not a calculator running locally. It is a service in which your text is transmitted, processed, and often also stored for some time on the provider's side. Depending on the plan and settings, it may be used to train future versions of the model, and fragments of conversations are sometimes reviewed by humans as part of moderation and quality control. This is not a conspiracy theory, just the standard mechanics of these services — and the starting point for any sensible working hygiene.

From this follows a simple guiding principle: treat a chat with an AI model as if you were talking to an outside contractor whom you don't know and have no way to vet. You wouldn't give such a person the password to your company email, nor send over your customer database "to check something." The same reflex should apply to the model. The other side of the coin is trusting the answers: the model can fabricate things smoothly and convincingly — invented legal provisions, nonexistent library functions, wrong calculations delivered with complete self-assurance. A model's output is a starting point for verification, not a finished verdict.

For a small business there is also a legal and organizational dimension. Feeding customers' personal data into a free consumer account is, in practice, entrusting data processing to an entity with which you have no signed data processing agreement (DPA) — and the terms of a consumer account do not substitute for such an agreement within the meaning of Article 28 of the GDPR. The solution is not to ban AI (people will use it anyway, just on the sly), but to establish a deliberate framework: appropriate plans, a clear policy, data anonymization, and a habit of verification. The rules below are the minimum worth starting from.

1. Never paste secrets — Passwords, API keys, access tokens, login credentials, private keys — all of it goes out to the provider's server and may end up recorded in logs or in the conversation history. If any secret has made its way into a chat, treat it as compromised and replace it (rotate the key, change the password).
2. Don't send PII, customer data, or materials under NDA — Personal data, customer documentation, company secrets, content covered by a confidentiality agreement — none of it should end up in a consumer-grade model. You have no control over where and for how long it will stay, or who will see it. Keep in mind, too, the "memory" features and saved history that persist your data across conversations — they are also places where sensitive content lingers for the long term.
3. Anonymize and pseudonymize before sending — If you have to analyze a real case, remove or replace names, addresses, numbers, company names, and other identifiers with placeholders. The model will usually handle a problem described in the abstract, without real data, perfectly well.
4. Check and turn off the use of conversations for training (opt out) — Some services use your conversations by default to train future models. You can usually disable this in the account settings — do it. This doesn't eliminate the risk of a leak, but it limits where your content ends up permanently.
5. For company data, use business/enterprise plans — Business/enterprise plans by default do not use your content to train models and let you sign a data processing agreement (DPA) — the foundation of GDPR-compliant processing of customer data. An important distinction: "no training on data" is not the same as "zero data retention" (ZDR). Even business plans usually store content for a certain period (e.g., for abuse detection); full ZDR — not retaining content at all — is typically a separate arrangement (often available for the API upon request). A free consumer account offers none of these guarantees.
6. Remember the GDPR when handling personal data — Putting customers' personal data into an AI cloud is data processing with concrete legal consequences: you need a legal basis, a data processing agreement (DPA), and control over where the data is processed (including outside the EU/EEA). Without this, you expose your company to real risk.
7. Treat every output as unverified — Models hallucinate — they produce made-up facts, nonexistent regulations, wrong quotes and calculations, and they do so in a thoroughly convincing tone. Verify facts, code, numbers, and sources in independent, reliable places before you rely on them.
8. Watch out for prompt injection — Don't have the model blindly carry out instructions contained in untrusted content — web pages, files, emails. Text hidden in such content can hijack the model's behavior (e.g., prompt it to send data or perform an unwanted action). Let the instructions come from you; external content is only data. The risk grows when the model has access to tools and integrations.
9. Be careful with plugins, integrations, and "actions" — Plugins, connectors, and agentic features (access to mail, files, the browser, external APIs) significantly expand the attack surface. Every integration is a new permission and a new risk — enable only the ones you actually need, and check what they have access to.
10. Do a code review of AI-generated code — Generated code can contain security holes, outdated patterns, vulnerabilities such as SQL injection, or faulty handling of input data. Read it just as critically as code from a new, unvetted developer — don't push it to production without a review.
11. Separate accounts and roles, no sharing — Every employee should have their own account, with access granted by role. Shared logins make auditing impossible, mix up conversation histories, and make it harder to cut off access once a person leaves the company.
12. Put in place an AI usage policy along with logging and auditing — Write down clear rules for the company: what may and may not be fed into the models, which tools to use, and on which plans. Add logging and a periodic review of usage to that — otherwise you have no idea what data is really leaving the organization.
13. Assume that conversations are sometimes reviewed by humans — As part of moderation and quality assessment, providers may route fragments of conversations for review by employees or subcontractors. Write on the assumption that a human may sit down on the other side of the screen — and don't send anything you wouldn't want to show a stranger. On enterprise plans with ZDR, such human review is usually disabled, but don't take that for granted without checking the contract.
14. Don't hand legal, medical, and financial decisions over to AI — A model can help you organize a topic and prepare questions, but it won't replace a lawyer, a doctor, or an advisor. In matters with real consequences, always verify the result with a qualified expert — responsibility for the decision stays on your side.

5. What to choose when

• › Non-sensitive data, a one-off text task (writing, learning, translation, brainstorming): use cloud chat — zero setup, the most powerful models, and the worst outcome is bad advice that you judge for yourself anyway. Verify the output wherever facts matter.
• › Company data or clients' personal data, but still a conversational mode: chat, but only on a business/enterprise plan with a signed data processing agreement (DPA) and training turned off — never on a free consumer account. Always anonymize whatever you can first.
• › You genuinely need to carry out multi-step work on your systems (code, automation, research with actions): an agent — but with least-privilege, in a sandbox or on a copy, and leave every irreversible action (sending, deletion, payment, publication) for a human to approve.
• › Sensitive, confidential, or trade-secret data that you don't want to send anywhere, or offline work: a local model (Ollama/LM Studio) — nothing leaves your machine. Accept weaker reasoning and hardware upkeep on your end, and keep the endpoint on localhost or behind authentication.
• › The overarching rule regardless of form: the more sensitive the data, the closer to the local end of the scale; the simpler and less risky the task, the more comfortably you can reach for cloud chat. There's no single right choice — there's matching to the sensitivity of the data and the nature of the task.

6. What next — worth exploring

1. Prompt injection in practice — what it looks like and how to defend against it — This is the most important AI-specific threat with agents and integrations; it's worth showing a real scenario (a hidden command in an email or web page) and concrete defense mechanisms: separating trusted from untrusted content, least-privilege, human-in-the-loop.
2. Verifying answers and hallucinations — methods for checking — Hallucinations also cover fabricated sources and citations. A practical hands-on guide (how to cross-check facts, code, and numbers, and when not to trust even the links provided) is concrete and useful for every reader.
3. Model provenance and the supply chain — where to get weights and GGUF files — With local models you download weights from external repositories; it's worth discussing trusted sources, the risk of poisoned or tampered weights, checksum verification, and model licenses (what's permitted commercially).
4. GDPR and clients' personal data in the day-to-day of a small business — Concrete obligations: a legal basis, a data processing agreement (DPA), transfers outside the EEA, and the difference between no training and zero data retention. This is a real legal risk that affects the PivLab audience directly.
5. RAG locally — your own knowledge base without sending documents to the cloud — A practical way to query contracts, procedures, and company documentation while preserving privacy; it's worth showing how to connect a local model to your own files and where the limits of this approach lie.
6. Least-privilege and human-in-the-loop for agents — how to implement it — The principle itself gets repeated, but the reader needs specifics: how to grant narrow permissions, how to run in a sandbox or on a copy, where to insert approval checkpoints, and how to audit the agent's chain of actions.
7. Security of AI-generated code — Generated code can be vulnerable (injections, poor validation, outdated patterns). It's worth providing a security-focused code review checklist and examples of the common mistakes that must never ship to production.
8. Vendor lock-in, costs, and predictability — Dependence on a provider (pricing, terms of service, model availability) and the unpredictable token cost with agents are real business risks. It's worth comparing the cloud cost model against investing in local hardware.
9. Deepfakes and AI-assisted social engineering — This extends the threat model beyond the user's own tools: a spoofed voice or video of the boss, personalized phishing. For a business this is a direct fraud risk, and it's worth providing identity-verification rules.
10. Air-gapping and a segregated network for sensitive AI deployments — For the most sensitive use cases it's worth showing how to physically or logically isolate the AI environment (no egress, VLAN, no internet access) and when this level of isolation makes sense.