AI literacy: what every employee should know before using AI at work.

AI literacy courses often open with how models work inside: neural networks, training data, tokens. Interesting, but little help on an ordinary afternoon, when the questions are smaller and more urgent. Can I paste this? Is this figure right? Can I send this to the customer?

Literacy at work is the knowledge that answers those questions: what these tools are good and bad at, which data must never go in, how to check an answer and when a person has to decide. None of it needs a technical background, and it fits on one page.

What does AI literacy mean at work?

Using AI tools well and safely in your own job: knowing where they help, where they fail, what they may see and what stays your responsibility. Here is the page.

1. It writes what is plausible, not what is true. Fluency proves nothing.
2. It is strong at language work: drafts, summaries, rewording, first-pass translation, pulling fields out of documents.
3. It is weak at facts it wasn’t given, at exact figures and at admitting it doesn’t know.
4. Use approved tools with your work account. Work data never goes into a personal account.
5. Check the acceptable use policy before you paste. Some data stays out even of approved tools.
6. Open the source behind any claim you will rely on.
7. Verify every number, name, date and amount against the system it came from.
8. Treat confidence as style, not evidence.
9. A person decides anything that costs money, commits the company, reaches a customer or can’t be undone.
10. You own what you send, and you report what goes wrong.

What are these tools good and bad at?

A language model produces the most plausible next words given what it has seen. That makes it very good at form: notes into a draft, a long thread into five lines, a scanned form into a table. It also makes it unreliable on content it wasn’t given: ask about your return policy without supplying it, and you get a plausible one.

Three limits matter most at work. It invents specifics, such as a clause number or a figure, in the same confident tone as everything else. It is unreliable at arithmetic across many numbers. And it can answer the same question differently twice. Tools connected to company documents help with the first, but can still retrieve the wrong passage or misread the right one.

Which data must never go into a tool?

That depends on the tool. An approved tool runs under terms your organization agreed: where data is processed, how long it is kept, whether it trains anything. A personal account runs under terms nobody at your company has read, which is why point four comes before any list.

Your acceptable use policy holds the list. The “never” column usually includes health and other special categories of personal data, passwords and access keys, payment card details and anything marked restricted. Customer and employee data, contracts and unpublished financial results sit under “ask first”.

Consider an illustrative case. A specialist needs a summary of a customer contract before a call and pastes all forty pages into a personal chat tool. The summary is good. The contract, with names, prices and bank details, now sits in an account the company doesn’t control. The one-page guide says to do three things instead: use the approved tool if the policy clears it for contracts; if not, ask the contract owner for the key terms; and if the paste has already happened, tell your manager and your data protection contact so they can assess it. Reporting should never be punished; that is how you hear about the next one.

How do you check an answer?

Match the effort to the stakes. A note to a colleague needs a read-through; a figure headed for a board pack needs a check against its source. Three habits cover most of it:

• Open the source. If the answer cites a document, read the passage. Does it say what the answer claims?
• Verify numbers and names. Amounts, dates, names and clause numbers get checked against the system they came from, never trusted from the text.
• Watch for confident errors. The dangerous answer isn’t the plainly wrong one. It is the right-looking one with a single wrong detail.

Asking the tool for its sources, assumptions and uncertainties makes checking faster; the note on why AI makes things up explains where the errors come from.

When must a person decide?

Whenever the output costs money, commits the company, reaches a customer or can’t be undone, and on any decision about people, such as hiring, performance or access. AI can gather, draft and check; a named person decides with the evidence in front of them. We design the same boundary into every system we build, with approval points and a fallback.

“The tool wrote it” is never an explanation.

How do you teach it without a lecture?

Short sessions, small groups, each team’s real work. Three exercises do more than any slide:

• Can I paste this? The team sorts its own document types into allowed, ask first and never, using the policy.
• Spot the error. A realistic answer with one planted wrong figure. Missing it once teaches more than being told.
• Check the source. Answer a real question with the approved tool, then verify every claim against the documents.

Run them in the language the team works in: Turkish, English or both. Keep the page where people use the tools, and update it when they change. If your organization is subject to rules that require AI literacy training, ask counsel what they require and how to record it. A curriculum by role builds on this baseline.

One team first

Print the ten points and test them with one team on its own documents; its questions will show which points need a second line. AI enablement turns a page like this into role-based training on real tasks.