AI Literacy.

Artificial intelligence is a field that develops systems able to perform tasks such as recognising patterns, producing language or supporting decisions. It is not a single tool, and it does not imply consciousness, intent or human understanding.

In machine learning, patterns are adjusted using data. Generative AI produces new content, such as text, images or code. Rule-based automation follows predefined instructions: sending a reminder on a set date may not require AI.

AI can help analyse information or produce a first draft, but its usefulness depends on the goal, data quality and human review. Before adopting it, compare it with a simpler solution and decide how you will check the result.

During training, a model adjusts parameters to reduce errors against a defined objective, using examples. During inference, it applies the learned patterns to a new input. Quality depends on the data, the training objective and the context in which the model is used.

A language model predicts sequences of text units called tokens. Its parameters do not work like a library of verifiable documents. A product may add search or other sources, but that is a specific capability that needs to be confirmed.

An answer can sound confident while containing invented facts, nonexistent references or incorrect reasoning. These errors are often called hallucinations. A confident tone is not a reliable measure of accuracy.

A model may also omit information, reproduce bias or answer the same question differently. Limitations vary by task and version. The greater the impact of an error, the more rigorous the checks and human oversight should be.

A good request identifies the goal, audience, relevant context, constraints and output format. Say how you will recognise a good answer. Merely assigning a role, such as “you are an expert”, does not guarantee knowledge or quality.

Separate your instructions from the documents to be analysed, and explain that those documents are reference material. Ask the system to flag gaps instead of filling them with guesses. A clear request improves direction but does not eliminate errors.

Break a complex task into parts: understand the requirements, produce a proposal, review it and test it. When an answer fails, describe the specific error and give an example of the expected result. Keep useful versions of your requests.

Compare the output with the original document, the requirements and a solution made without AI. Ask for short explanations and verifiable evidence, without treating a persuasive explanation as proof. For code or calculations, run tests and validate results.

Before entering data into a tool, check authorisation, purpose, service terms, retention and access. Business and personal accounts may have different settings and contracts. Do not assume confidentiality merely because a service is paid.

Use only the information needed. Removing a name may not anonymise a document: roles, dates and events can also identify someone. Never share passwords, API keys or authentication codes. Sensitive data requires its own assessment.

Open cited sources and find the passage supporting each important claim. Check the author, date, context and version. A real reference may have been misinterpreted, and several pages may repeat the same error.

Prefer primary documents for legal requirements, data and technical specifications. For calculations, check units, assumptions and formulas with an appropriate tool. Asking the same model to confirm its own answer is not independent verification.

Data can reflect inequalities, omissions or a reality unlike the one in which a system will be used. A good average result can hide failures in one language, group or type of case. Look for who is poorly represented.

Define what would count as a significant error and compare results across relevant scenarios while respecting privacy. Include people who know the context in the evaluation. No single metric proves fairness, suitability or the absence of discrimination.

Content available online is not necessarily free of copyright restrictions. Personal data remains subject to applicable rules when processed with AI. Check licences, purpose and contractual terms before reusing data or publishing outputs.

Article 4 of the EU AI Act addresses the AI literacy of people operating systems in covered contexts. The GDPR and other rules may also apply. The specifics depend on the organisation’s role, the system and its use; reading this guide does not replace that assessment.

Describe the current process: inputs, tasks, owners, decisions, exceptions and the expected output. Identify the specific problem and establish a baseline, such as time spent, rework or errors. Compare AI with simplification, training or conventional automation.

Assess whether suitable data, authorised access and the means to maintain the solution are available. The existence of a tool does not make an opportunity viable. Automating an unstable process with no owner may simply create problems faster.

Define what the system may suggest, read, change or send. Separate preparing an action from executing it. Operations with financial, legal or third-party impact may need explicit approval. Oversight needs time, information and authority to intervene.

Apply least privilege: give each integration only the access it needs. Plan for exceptions, failures and a way to stop the system. An approval button that is hard to understand or triggered automatically is not meaningful human control.

Start with a limited scope and acceptance criteria set before testing. Compare with the baseline and also record errors, review cost, exceptions and effects on people. Time saved at one step may be lost at another.

Choose a representative set of cases, including difficult situations. Decide in advance when to continue, correct or stop. A successful demonstration does not prove production readiness, financial return or reliability at scale.

Tokens are units used to represent text; they do not always correspond to whole words. A context window limits the information processed in one interaction. More context does not guarantee equal attention to every detail or a better answer.

Settings such as temperature affect sampling when available. A low temperature does not guarantee truth or perfectly deterministic results. Record the model, version, request, sources and settings when comparing experiments. Consider latency, usage limits and total cost.

Retrieval-augmented generation (RAG) combines information retrieval with generation: it finds documents or excerpts and gives them to a model as context. Embeddings represent information as vectors to support similarity searches. Search may also combine keywords, filters and result reranking.

Quality depends on document preparation, retrieval, permissions and how answers use sources. RAG does not eliminate hallucinations or make documents automatically safe. Fine-tuning changes a model’s behaviour using examples; it is not the same as maintaining an up-to-date document collection.

Build test cases with inputs and expected results or evaluation criteria. Keep examples used during development separate from a reserved set for testing changes. Include normal cases, edge cases, missing information and adversarial inputs.

In classification, precision and recall measure different things; false positives and false negatives can have different costs. In retrieval, metrics such as recall@k assess whether relevant information was found. For generation, combine source checks, rules and human review. An AI-based evaluator also needs validation.

Compare solutions for quality, privacy, cost, latency, availability and maintenance. A larger model, a chain of agents or self-hosted infrastructure is not automatically better. More components bring more dependencies and failure modes to understand.

Define input and output contracts, size limits, timeouts, concurrency controls and failure behaviour. Automatically retrying an operation that sends messages or charges payments can duplicate effects. Consider idempotency, retry limits and compensating actions where relevant.

An agent combines a model, tools and a decision loop. Text from pages, messages or documents may contain malicious instructions, known as prompt injection. Treat that content as untrusted data, not permission to act.

Security controls must exist outside the model: authentication, authorisation, parameter validation, restricted tools and confirmation for sensitive effects. Separate data and secrets, restrict network destinations where appropriate and keep proportionate logs. Asking a model to “ignore attacks” is not a sufficient security boundary.

Version models, requests, sources, configurations and evaluations. Changes to a provider, documents or user habits can alter behaviour. Monitor quality by scenario, incidents, latency and costs, using logs that do not expose personal data unnecessarily.

Assign owners, periodic reviews, access management, incident response and criteria for pausing or rolling back. Drift means relevant changes in data or the relationships observed; not every performance decline has the same cause. Investigate before adjusting, and revalidate controls after changes.