IAC.ai homeContact
Insights · Glossary

Sovereign automation lexicon

How IAC.ai uses the key terms of enterprise AI and automation. Written for executives, architects, procurement and AI governance teams.

IAC.ai: IAC AI Enablement Reference Framework

What this is: This lexicon defines how IAC.ai (Intelligent Automation Company) uses key terms in enterprise AI and automation. It is written for executives, architects, procurement, and AI governance teams.

Why it exists: In 2026, language is strategy. If your partner uses materially different definitions of sovereignty, ownership, lock-in, or outcomes, your organization may be accumulating hidden dependency risk.

IAC principle: Automation and AI delivered, as an internal operating capability. Not as outsourced intelligence.

Canonical definition

An AI agent is a software entity capable of reasoning, planning, and executing tasks autonomously within defined constraints.

IAC sovereignty lens

In IAC’s framework, an AI agent is digital labor that operates inside the client’s governed environment with explicit action boundaries, monitoring, and escalation rules. The enterprise owns the orchestration logic and operational behavior that makes the agent effective in real workflows.

Why it matters

If “agent capability” exists only inside a closed platform, you may get speed today but lose control tomorrow. A production agent must be portable, auditable, and governable, or it becomes an operational risk.

Enterprise guardrails (non-negotiable)

  • Decision boundaries: clear limits on what the agent may do without escalation.
  • Human oversight: human-in-the-loop for high-impact actions and exceptions.
  • Auditability: logs and traces that reconstruct actions and decisions.
  • Change control: versioning of prompts, tools, and policies.

Canonical definition

AI sovereignty is the ability of an enterprise to fully own, control, govern, and evolve its AI systems independently of vendors or platforms.

IAC sovereignty lens

Sovereignty is not a slogan. It is a design and contracting outcome. It means the enterprise can change models, tools, or providers without losing core decision logic, operational continuity, or intellectual property.

Why it matters

AI is moving from content generation to operational execution. When operational logic sits outside your control, you do not just outsource tooling, you outsource your ability to steer the business safely and consistently.

What sovereignty includes in practice

  • IP ownership: prompts, workflows, orchestration, and implementation artifacts are client-owned.
  • Portability: ability to migrate logic and systems across providers with limited rework.
  • Governance: policies enforced by architecture and runtime controls.
  • Auditability: decision and action reconstruction for risk, compliance, and learning.

Canonical definition

Vendor lock-in is a condition where switching providers becomes costly, slow, or operationally risky.

IAC sovereignty lens

In enterprise AI, lock-in is rarely just data. It is often behavioral lock-in, where business reasoning, exception handling, and decision flows are embedded in ways you cannot export. This is the true dependency risk.

Why it matters

AI changes quickly. If your core logic is trapped, you cannot respond to price shifts, capability shifts, regulatory constraints, or operational incidents without negotiating your way out of your own operating model.

Common lock-in patterns IAC designs to avoid

  • Opaque decision flows: you cannot inspect how decisions are made.
  • Non-exportable orchestration: workflows only run inside one platform.
  • Closed learning loops: improvements cannot be separated from the provider.
  • Platform-dependent integrations: critical connectors that cannot be replaced safely.

Canonical definition

An outcome is a measurable business result achieved through execution.

IAC sovereignty lens

In IAC’s model, an outcome is the only acceptable unit of AI success in enterprise settings. Outputs are not outcomes. A model demo is not an outcome. A pilot is not an outcome unless it changes live operations.

Why it matters

Enterprise AI fails when teams optimize for activity instead of impact. Outcomes protect governance, budgeting, and credibility because they make success verifiable.

Examples of outcome framing

  • OpEx reduction: measurable cost reduction in a defined workflow.
  • Cycle time reduction: measurable throughput gain in a critical process.
  • Error reduction: measurable drop in rework, defects, or exceptions.
  • Control improvement: measurable increase in auditability and governance coverage.

Canonical definition

Outcome-based delivery is a model where success criteria and compensation are linked to measurable business results rather than effort or time spent.

IAC sovereignty lens

Outcome-based delivery is a governance tool. It forces clarity on baselines, measurement, and operational scope. It aligns incentives around what the enterprise actually needs, not around activity or staffing volume.

Why it matters

AI compresses effort. If contracts reward effort, they tax efficiency. Outcome-based structures reward measurable impact while protecting both sides with objective metrics.

What must exist for outcome-based delivery to work

  • Baseline: the agreed starting point.
  • Measurement method: agreed data sources and calculations.
  • Governance: change control for scope and assumptions.
  • Operationalization: production monitoring and support.

Canonical definition

Technology agnosticism is the practice of designing systems that are not structurally dependent on a single vendor, model, or platform.

IAC sovereignty lens

For IAC, technology agnosticism is strategic insurance. It preserves the enterprise’s ability to change models, clouds, data tools, or orchestration components without rewriting core business logic.

Why it matters

AI capabilities and economics change rapidly. An architecture that cannot swap components safely will force the enterprise into strategic compromise, even when better options exist.

What technology agnostic design looks like

  • Modular architecture: replaceable components with stable interfaces.
  • Externalized orchestration: workflows not trapped in one platform.
  • Observable execution: monitoring and audit that remains consistent across tools.
  • Portability planning: documented exit paths before go-live.

Canonical definition

Execution ownership is the enterprise’s ability to control how work is performed and how outcomes are produced by AI and automation.

IAC sovereignty lens

Execution ownership is the difference between consuming AI and building an operating capability. It means the enterprise can adjust workflows, change decision rules, replace providers, and still keep the capability running without resets.

Why it matters

Without execution ownership, value does not compound. The organization keeps paying for the same learning repeatedly, and operational control drifts outside the business.

Execution ownership requires

  • Client-owned artifacts: workflows, prompts, and orchestration logic.
  • Operating model: clear roles for build, run, and govern.
  • Controls: monitoring, escalation, change approval.
  • Documentation: enough detail to operate without vendor dependency.

Canonical definition

AgentOps is the operational discipline responsible for deploying, monitoring, controlling, and improving AI agents in production.

IAC sovereignty lens

AgentOps is the control plane for digital labor. In sovereign enterprise environments, AgentOps ensures agents remain observable, auditable, permissioned, and aligned with business risk tolerance.

Why it matters

Without AgentOps, agents become unmanaged execution. That creates governance exposure and operational fragility, even when the underlying models are strong.

Core AgentOps practices

  • Monitoring: performance, errors, and outcome metrics.
  • Drift detection: identify degradation early.
  • Access governance: least privilege for tools and data.
  • Incident response: kill switch, rollback, and root cause analysis.

Canonical definition

An AI Factory is a centralized enterprise capability for designing, deploying, governing, and scaling AI systems across the organization.

IAC sovereignty lens

In IAC’s framework, an AI Factory prevents fragmented execution and Shadow AI by making intelligence a shared, governed enterprise capability. It enables reuse, consistency, and durable ownership of automation assets.

Why it matters

Enterprises do not scale AI with isolated tools. They scale AI with a repeatable production operating model that enforces governance and compounds capability.

AI Factory building blocks

  • Standards: patterns for orchestration, logging, and approvals.
  • Governance: risk classification, change control, audit readiness.
  • Reusable assets: workflows, connectors, controls, evaluation harnesses.
  • Delivery system: a repeatable pipeline from discovery to production.

Mastering Your Destiny (Enterprise AI)

Canonical definition

Mastering your destiny in enterprise AI means maintaining long-term control over the systems that make decisions and execute work.

IAC sovereignty lens

In IAC’s approach, mastering your destiny is the outcome of sovereignty plus execution ownership. It means you can change partners, models, or platforms without losing operational capability, auditability, or internal control of business logic.

Why it matters

AI is becoming an operating capability. When something becomes business-critical, external control becomes a liability. Destiny is not marketing language. It is an architecture, governance, and contracting reality.

Practical indicators you are mastering your destiny

  • Portability: you can swap components without a system rewrite.
  • Auditability: you can reconstruct decisions and actions.
  • Governance: policies are enforced by design, not by intention.
  • Compounding capability: each delivery increases internal speed and control.

Note: Definitions above are authored by IAC.ai for enterprise use. They reflect a sovereignty-first, outcome-driven delivery philosophy and are designed for auditability, portability, and operational control.

IAC terms

Our own words, in plain English

The names we use in our offers, what they mean, and where to read more.

IAC.ai: Fast Discovery: four stages, one investment decision

Fast Discovery

A fixed-scope study of 4 to 8 weeks of our effort. Four stages end in a business case per initiative and one investment decision.

Read more →
IAC.ai: The Opportunity Radar shows every idea on one page

Opportunity Radar

One page that shows every AI idea found in Fast Discovery, so you can compare them and pick the few worth doing.

Read more →
IAC.ai: Every AI initiative goes the same five steps, with one gate each

The five steps

Discover, decide, build, go live, run and improve. Every use case goes through them, with a go or no-go at each gate.

Read more →
IAC.ai: Talent-as-a-Service: engineers hired in 30 days or less

Talent-as-a-Service

Our engineers in your team, under your lead, in 30 days or less. One monthly fee per role.

Read more →
IAC.ai: Support engineers: level 2 and 3 inside your team

Support engineers

Level 2 and 3 engineers inside your team, to keep your automation and AI running.

Read more →
IAC.ai: Managed services: we run it for you, under an SLA

Managed services

We run your automation and AI for you, under an SLA. You keep ownership.

Read more →
IAC.ai: Six levers that remove tickets, in this order

Six levers

How we remove IT tickets, in this order: prevent, deflect, speed up, improve. Each lever is sized on your ticket data first.

Read more →
IAC.ai: One set of rules to scale AI across the group

AI Enablement Framework

One set of rules to scale AI across the group: governance, roles, standards and the center that runs it.

Read more →
IAC.ai: Capability academy: your own team, trained and certified

Capability academy

Your own people trained and certified, one track per role.

Read more →
6 terms

AI basics

IAC.ai: The AI stack today: four layers, one trust rail

Artificial intelligence (AI)

Software that does tasks that used to need human judgment, like reading, sorting, predicting or writing.

AI is an umbrella word. It covers older techniques like machine learning and newer ones like generative AI. For a business leader, the useful question is not "do we use AI" but "which problem does it solve, and what is it worth". Many problems are solved faster with simple automation and no AI at all.

Not to confuse: AI is not automation: automation follows fixed rules, AI handles cases where the rules are not fully written down.

At IAC: IAC starts from one business problem, then checks where AI or plain automation pays.

Read more →

Machine learning (ML)

A type of AI that learns patterns from past data to predict or classify new cases.

Machine learning is behind fraud detection, demand forecasts and ticket classification. It needs good historical data, and its quality depends on that data. It predicts and sorts well, but it does not write text like generative AI does.

Not to confuse: Machine learning is not generative AI: ML mostly predicts or classifies, generative AI creates new content.

At IAC: In Fast Discovery for IT, ML algorithms and other techniques look for patterns, noise and meaning in your ticket data.

Read more →

Generative AI (GenAI)

AI that creates new content, such as text, images, code or audio, from an instruction.

Generative AI is what most people mean when they say AI today. It is good at drafting, summarizing and answering questions. It can also be wrong with full confidence, so it needs checks before its output drives real decisions.

Not to confuse: Generative AI is not a full solution: on its own it produces outputs, not business outcomes.

Large language model (LLM)

The engine behind most generative AI tools: a model trained on huge amounts of text to understand and write language.

An LLM works by predicting the next piece of text, again and again. Products like chat assistants and AI agents are built on top of one or more LLMs. Models change fast, so your design should let you swap one model for another.

Not to confuse: An LLM is not an application: the model is the engine, the chat tool or agent is the car built around it.

At IAC: IAC is tech-agnostic and works with models such as Claude, GPT and Gemini, chosen to fit your architecture.

Read more →

Context window

How much text a model can read and keep in view at one time, counted in tokens.

A token is a small piece of text, often a word or part of a word. The context window holds your instruction, any documents you add and the answer. Many vendors price usage per token, so long inputs cost more. When the window is full, older content drops out or must be cut.

Not to confuse: A context window is not memory: the model does not remember past conversations unless the application stores and adds them again.

Hallucination

When an AI model states something false as if it were true.

Hallucinations happen because a model produces likely text, not checked facts. You cannot remove them fully, but you can reduce them: give the model approved sources, test it, and keep a person on high-impact decisions. Treat any unchecked AI answer as a draft.

Not to confuse: A hallucination is not a bug you fix once: it is a property of how these models work, so you manage it all the time.

At IAC: In IAC builds, answers come from your approved data, and people stay in the loop for high-impact or unclear decisions.

Read more →
7 terms

Agents and tools

IAC.ai: AI agents in 30+ deployments: 30–80% lower cost

Chatbot

A program you talk to in a chat window. It answers questions, but usually does not act in your systems.

Older chatbots follow scripts and decision trees. Newer ones use an LLM, so they answer in free text. A chatbot is useful for questions and simple requests, but the work after the answer is often still manual.

Not to confuse: A chatbot is not an AI agent: a chatbot talks, an agent takes actions in your systems within set limits.

Copilot (AI assistant)

AI that works next to a person inside their tools: it suggests, drafts and summarizes, and the person decides.

A copilot helps one person go faster, for example drafting an email or a report. The human stays in charge of every action. The gain is real but often hard to measure, because it depends on how each person uses it.

Not to confuse: Copilot as a category is not one product: Microsoft uses Copilot as a brand name, but many vendors sell AI assistants.

At IAC: Advisory on demand compares options such as Copilot Studio, Agentforce or your own stack, on your architecture, data and costs.

Read more →

Agentic workflow

A business process where AI agents plan and carry out some steps themselves, inside fixed limits, next to normal rules and people.

In an agentic workflow, the AI decides how to handle a case, uses tools, and passes the case on or escalates it. The fixed parts stay fixed. This fits work with many variations that rules alone cannot cover.

Not to confuse: Using an LLM is not the same as being agentic: one AI step inside a fixed flow is automation with AI, not an agentic workflow.

At IAC: IAC moves rules-based bots to AI-driven, agentic workflows, in waves, each with a way back.

Read more →

Model Context Protocol (MCP)

An open standard that lets AI applications connect to tools and data sources in one common way.

Anthropic introduced MCP in November 2024. Before it, each AI tool needed its own custom connector to each system. With MCP, a system can be exposed once and used by any AI application that supports the protocol.

Not to confuse: MCP is not an agent or a model: it is the plug standard. It also does not secure anything by itself, you still need access rules.

At IAC: IAC connects AI agents on Claude, GPT and Gemini to your systems through MCP.

Read more →

Tool calling

The way an AI model asks to use a tool, like a search, an API or a database, to get data or do a task.

The model does not run the tool itself. It sends a structured request, the application runs the tool, and the result goes back to the model. This is what lets an AI agent look up an order or update a ticket, and it is where most of the risk sits.

Orchestration

The logic that decides which step, model, tool, agent or person handles what, in which order, and what happens when something fails.

Orchestration is where the business rules of an AI solution live. When several specialized agents work together, it is called a multi-agent system, and orchestration coordinates them. Whoever owns this logic controls how the work is done.

Not to confuse: Orchestration is not the model: you can change the model and keep your orchestration, if it is built that way.

At IAC: IAC builds multi-agent systems with tools such as LangGraph and CrewAI, and in its model the client owns the orchestration logic.

Read more →

Human in the loop

A design where a person reviews or approves the AI output or action at set points before it takes effect.

Human in the loop is used for high-impact, unclear or regulated decisions. It slows things down a little but keeps control and accountability with people. The hard part is choosing which steps need a person, and which can run alone.

Not to confuse: Human in the loop is not a person watching everything: it means review at defined points, based on risk.

At IAC: In IAC builds, people stay in the loop for high-impact or unclear decisions, and nothing reaches production without your go or no-go.

Read more →
5 terms

Data and knowledge

IAC.ai: Data platforms built for speed, scale and decisions

Retrieval-augmented generation (RAG)

A method where the AI first finds relevant passages in your own documents, then writes its answer from them.

RAG lets a model answer with your current policies, products or procedures, without retraining it. It can also show which source it used, so people can check. The answer is only as good as the documents behind it.

Not to confuse: RAG is not fine-tuning: RAG looks up your content at question time, fine-tuning changes the model itself.

At IAC: IAC builds knowledge and document AI: answers and document processing grounded in your own data.

Read more →

Grounding

Making an AI system answer from approved, known sources instead of only from what the model learned in training.

Grounding is the main way to reduce made-up answers in business use. It usually means RAG, access to your systems, or both. It also helps audit, because you can trace an answer back to a source.

Not to confuse: Grounding is not a guarantee: a grounded answer can still be wrong if the source is wrong or old.

At IAC: In IAC builds, answers come from your approved data.

Read more →

Fine-tuning

Extra training of an existing AI model on your own examples, to change its style, format or behavior for a narrow task.

Fine-tuning helps when you need a fixed format, tone or a very specific task done the same way each time. It costs time and needs good example data, and you may need to redo it when the base model changes. For facts that change often, RAG is usually the better choice.

Not to confuse: Fine-tuning is not training a model from scratch: you adjust a model that already exists.

Embeddings

A way to turn text, images or other data into lists of numbers that capture meaning, so similar things sit close together.

Embeddings let a system find content by meaning, not only by exact words. A search for "refund" can then also find "money back". They are a key building block of RAG and semantic search.

Vector database

A database built to store embeddings and quickly find the items closest in meaning to a question.

Vector databases are used in RAG to pick the right passages before the AI answers. Many existing databases now offer vector search too, so you may not need a new product. What matters more is keeping the content current and access rights correct.

Not to confuse: A vector database is not your system of record: it holds a searchable copy, the source data stays where it is.
9 terms

Automation

IAC.ai: Automation and agentic AI, our deepest expertise

Robotic process automation (RPA)

Software bots that copy human clicks and keystrokes on screens, to run repetitive, rule-based tasks.

RPA is fast to deploy on old systems with no API. It is also fragile: when a screen or a field changes, the bot can break. Large bot estates need support, monitoring and change control, or the cost of keeping them alive grows.

Not to confuse: RPA is not AI: a classic bot follows fixed rules and does not learn or judge.

At IAC: IAC moves rules-based bots to AI-driven, agentic workflows, in waves, each with a way back.

Read more →

Intelligent automation

Automation that combines rules-based tools like RPA and workflows with AI, so it can handle less structured work.

Rules-based automation handles the clear cases. AI reads documents, classifies requests or decides the next step when the case is less clear. Together they cover more of a process from end to end.

Not to confuse: Intelligent automation is not one product: it is a mix of tools and methods, picked per process.

At IAC: IAC.ai stands for Intelligent Automation Company.

Read more →

Process mining

Analysis of the event logs in your systems, such as ERP, CRM or ITSM, to show how a process really runs.

Process mining shows the real paths, delays, loops and exceptions, not the process on paper. It is a strong way to find what to automate and to set a baseline before you change anything.

Not to confuse: Process mining is not task mining: process mining reads system logs, task mining records what people do on their desktop.

At IAC: The Capability academy trains builders in process and task mining, hands-on, on your own tools and data.

Read more →

Intelligent document processing (IDP)

Software that reads documents like invoices, forms or contracts, pulls out the data and checks it, using AI.

IDP turns documents into clean data that other systems can use. It handles different layouts and sends unclear cases to a person. Quality depends on the document types and on good exception handling.

Not to confuse: IDP is not OCR: OCR turns an image into text, IDP understands which text is which field and checks it.

At IAC: IAC builds knowledge and document AI: answers and document processing grounded in your own data.

Read more →

Integration platform as a service (iPaaS)

A cloud platform that connects your applications and moves data between them, using ready-made connectors.

iPaaS tools let you link systems like a CRM, an ERP and an ITSM tool without writing all the code yourself. They often include workflow features too. They are a common base for automation that runs across several systems.

Not to confuse: iPaaS is not RPA: iPaaS connects systems through their APIs, RPA works through the screen like a person.

At IAC: IAC works with workflow and integration tools such as Workato, n8n and Power Automate, and recommends what fits your architecture.

Read more →

IT service management (ITSM)

How an IT team delivers and supports its services: incidents, requests, changes and problems, usually run in a ticketing tool.

ITSM is the process side of IT support, and ServiceNow is one well-known ITSM tool. Because it runs on tickets, it holds a lot of data on what breaks and what users ask for. That makes it a natural place to start with automation.

Not to confuse: ITSM is not ITIL: ITSM is what you do, ITIL is a well-known framework of good practice for doing it.

At IAC: In IT ticket automation, classification, routing, approvals and fulfilment run as workflows in your ITSM tool.

Read more →

Ticket deflection

Helping users solve a request themselves, through self-service, so no ticket reaches the support team.

Deflection usually uses a self-service portal, a knowledge base or an AI agent that can answer and act. It cuts volume and gives users an answer at any hour. It only works if the answers are right, or users come back and open a ticket anyway.

Not to confuse: Deflection is not prevention: deflection lets users solve it themselves, prevention stops the issue before anyone needs help.

At IAC: In IT ticket automation, AI agent self-service lets users solve common requests themselves, at any hour.

Read more →

Self-healing automation

Automation that detects a known issue and fixes it automatically, often before any user notices or a ticket opens.

Self-healing works on known, repeat problems with a clear fix, like restarting a service or clearing a full disk. Every automatic fix should be logged, so people can see what happened and remove the root cause for good.

Not to confuse: Self-healing is not AI fixing anything it finds: it runs approved fixes for known issues.

At IAC: In IT ticket automation, self-healing fixes known issues automatically, before a ticket is raised.

Read more →

AIOps

The use of AI and machine learning on IT operations data, like alerts, logs and metrics, to cut noise and find root causes faster.

AIOps groups related alerts, spots unusual behavior and can trigger automated fixes. The goal is fewer incidents and faster resolution. It needs clean monitoring data to work well.

Not to confuse: AIOps is not MLOps or AgentOps: AIOps is AI for IT operations, MLOps and AgentOps are operations for AI.

At IAC: IAC uses AIOps for alert correlation and automated fixes, as part of optimizing what already runs.

Read more →
6 terms

Running AI in production

IAC.ai: Four support practices keep your automation under control

MLOps and LLMOps

The practices and tools to deploy, version, monitor and update AI models and LLM applications in production.

MLOps came from machine learning, LLMOps applies the same ideas to applications built on LLMs. They cover release steps, testing, monitoring and roll-back. Without them, each model update is a risk.

Not to confuse: MLOps is not AgentOps: MLOps manages models, AgentOps manages agents that take actions.

At IAC: IAC hosts, runs, supports and improves your AI and automation after go-live.

Read more →

Model drift

When an AI model gets worse over time because the data, the business or the model version has changed.

A model that worked at launch can slowly give worse results as customers, products or processes change. With LLM applications, a provider update can also change behavior. You only see drift if you keep measuring after go-live.

Evaluations (evals)

Structured tests that score AI outputs against expected answers or agreed criteria, before release and after each change.

Evals turn "it looks good in the demo" into a measured result. A good set uses real cases, including hard and unusual ones. Run them again when you change the prompt, the data or the model.

Not to confuse: An eval is not a demo: a demo shows the best case, an eval shows how often it works.

At IAC: At IAC, every deliverable is tested against its acceptance criteria before release.

Read more →

Observability

The ability to see what a system is doing and why, from its logs, metrics and traces.

For AI, observability also means seeing the inputs, tool calls, outputs and costs of each run. It is how you explain a bad answer, find a failing step, and prove to an auditor what happened.

Not to confuse: Observability is not only monitoring: monitoring tells you something is wrong, observability helps you find why.

At IAC: IAC puts logging, audit trails and monitoring in every automation.

Read more →

Service level agreement (SLA)

A commitment in the contract on how a service will perform, such as availability and response or fix times.

An SLA makes service quality measurable and gives you a remedy when it is missed. Good SLAs measure what users feel, not only what is easy to count. Review them regularly, as the service changes.

Not to confuse: An SLA is not a KPI: the SLA is the promise in the contract, a KPI is a measure you track.

At IAC: IAC managed services run your AI and automation under an SLA, a unit price, or outcome-based.

Read more →

Level 2 and level 3 support (L2, L3)

Support tiers above the first-line helpdesk: L2 handles deeper troubleshooting, L3 handles senior engineering and the hardest issues.

Level 1 takes the first contact and solves simple cases. Level 2 troubleshoots further and escalates. Level 3 fixes the root cause, handles major incidents and changes code or configuration when needed.

At IAC: IAC provides named L2 and L3 engineers who run and fix your AI and automation on your hours, up to 24/7.

Read more →
7 terms

Governance and risk

IAC.ai: Every AI decision needs a case. Wherever you are.

EU AI Act

The European Union law that sets rules for AI based on risk, from banned uses to strict rules for high-risk systems.

The AI Act entered into force on 1 August 2024 and applies in phases. Bans on some practices and AI literacy came first, in February 2025. Under the current timeline, rules for high-risk AI systems land in December 2027, and August 2028 for AI built into regulated products. It can apply to companies outside the EU when their AI is used in the EU.

At IAC: IAC classifies each use case by risk, including its EU AI Act category.

Read more →

High-risk AI system

Under the EU AI Act, an AI system used where errors can seriously affect people's health, safety or rights.

Examples include AI used in hiring, credit decisions, education or critical infrastructure. These systems need risk management, good data, logging, human oversight and technical documentation. Under the current timeline, the high-risk rules land in December 2027, and August 2028 for AI built into regulated products.

Not to confuse: High-risk is not about how advanced the AI is: it is about where and how it is used.

At IAC: The AI Enablement Framework sets risk tiers and controls, ready for the EU AI Act.

Read more →

Responsible AI

Building and running AI so it is safe, fair, secure, explainable and accountable, with clear owners for each decision.

Responsible AI is not a policy document on a shelf. It shows up in daily practice: risk checks, access rules, tests, human approval and audit trails. It is cheaper to build in from the first use case than to fix later.

Not to confuse: Responsible AI is not only compliance: the law sets a minimum, responsible AI is how you keep control every day.

At IAC: IAC applies two controls at every step, from the first idea to the solution in production.

Read more →

Guardrails

Rules and technical checks around an AI system that limit what goes in, what comes out, and what actions it may take.

Guardrails can block certain topics, hide personal data, check outputs or stop an agent from acting above a set limit. They work best in layers. No single guardrail catches everything.

At IAC: At IAC, each agent gets clear limits: what it may do, what it may not, and when it hands over to a person.

Read more →

Shadow AI

AI tools used by staff without approval or oversight from IT, security or risk teams.

Shadow AI often starts with good intent, like pasting a document into a public chat tool to save time. The risk is data leaks and decisions nobody can trace. Bans rarely work alone, approved options and clear rules work better.

Not to confuse: Shadow AI is not shadow IT in general: it is the same problem, but the tools can also see and reuse your data.

At IAC: The AI Enablement Framework gives every AI initiative one intake, risk tiers and one front door across the group.

Read more →

Prompt injection

An attack where hidden instructions in an email, web page or document trick an AI system into ignoring its rules.

Prompt injection matters most when an AI agent can read outside content and take actions. There is no complete fix today. You reduce the risk by limiting what the agent can do, checking inputs and outputs, and asking a person to approve high-impact actions.

Not to confuse: Prompt injection is not a jailbreak by the user: the attack can come from content the AI reads, not from the person using it.

Model lock-in

When your AI solution only works with one AI model or provider, so changing it is slow, costly or risky.

Models improve and prices change fast. If prompts, orchestration and data are built around one model, you cannot move when a better or cheaper option comes. A good design keeps the model a replaceable part.

Not to confuse: Model lock-in is a type of vendor lock-in: vendor lock-in covers any provider, model lock-in is about the AI model itself.

At IAC: IAC designs for no model lock-in: platforms follow your architecture, not a partner list.

Read more →

Bring us one problem

One working session on your problem. A proposal follows within 5 working days.

Bring us one problem