Fractional Chief AI Officer for 30–300 person companies: AI governance that passes procurement and agentic automation shipped to production.https://meshin.co/Fri, 02 Oct 2026 00:00:00 GMThttps://meshin.co/glossary/ai-operating-modelhttps://meshin.co/glossary/ai-operating-modelAn AI operating model names who chooses, reviews and runs a company's AI work. What it covers has no standard definition, so check which one is in use.Fri, 02 Oct 2026 00:00:00 GMTWhy it comes up No standard defines the term, so a board that asks someone to build one has no standard definition to hand them. What to do about it Answer the three questions for one real system, and write a name beside each answer on one page. Then decide what else the company needs. The article on how to choose an AI operating model for a mid-size company covers the legal duties and the evidence. It also says how to choose, and where the evidence runs out. Treat any structure sold as the answer with caution, because no source reviewed shows that one structure works best.glossaryhttps://meshin.co/glossary/dpiahttps://meshin.co/glossary/dpiaA DPIA, or data protection impact assessment, is a written GDPR check of privacy risk before high-risk personal-data processing begins.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Almost any AI system worth building processes personal data, which makes a DPIA the default question rather than an edge case. Legal or procurement asks for it specifically once a system moves from a prototype to something touching real customer records. People often confuse it with the newer AI Act impact assessment. That is why explaining the difference is usually the more useful answer than either document alone. When monitoring staff triggers one Article 35(3) names three cases, but Article 35(1) asks for a DPIA wherever processing is likely to result in a high risk to people. The Article 29 Working Party's 2017 guidelines list criteria that point to high risk. Systematic monitoring is one. Data about vulnerable people is another, and employees may count as vulnerable because of the power imbalance. Meeting two criteria means a DPIA in most cases. Whether a dashboard of AI tool usage counts as systematic monitoring depends on how person-level it is. That is an inference, not a regulator's ruling. What to do about it Write the DPIA before the system is built, not after, since a risk found during design is cheap to change. The same risk found after launch usually is not. Start from what the system actually collects and why, not from a template's headings. Consult the data protection officer while there is time to act. The AI Governance Starter Kit lays out the same data classification a DPIA starts from.glossaryhttps://meshin.co/glossary/mcphttps://meshin.co/glossary/mcpThe Model Context Protocol (MCP) connects AI agents to tools and data, but cannot enforce consent, data privacy or tool safety at the protocol level.Fri, 02 Oct 2026 00:00:00 GMTWhy it comes up In this site's reading, it comes up when a team connects an agentic workflow to its own systems and a security reviewer asks what the agent can touch. "Open protocol" can sound like a safety claim. It is not one. A 2026 sheet from the US National Security Agency (NSA) says MCP's security posture "remains uneven and highly dependent on implementation discipline rather than protocol guarantees". The sheet cites the November 2025 revision of the specification. What to do about it The model picks which tool to call, and text it reads can steer that choice. That is prompt injection. The MCP project's security policy says a report that an LLM invoked an unexpected tool is not an MCP vulnerability. So the limits go in the host and the servers, as guardrails in code. Give each server only the access its task needs. That is least privilege. The NSA sheet recommends that tool execution be constrained and sandboxed. I start every new tool read-only. Any action that writes, spends money or touches personal data needs approval from a named person. Credentials live with the gateway or the server, never in the prompt, and they rotate every quarter. Before a third-party server connects I pin the exact version of a third-party server and review its source before it connects. The approved-server list lives in the client's AI register. Where the specification stops The specification, in its 28 July 2026 revision, names who should do the first three jobs. The protocol does not check that anyone does. - Approval before a tool runs: the host. There should always be a human in the loop who can deny a call. - Checks on inputs and access: each server. Servers must validate all tool inputs and implement proper access controls. - Logs: the host's clients. They should log tool usage, which feeds observability. MCP traffic goes through the gateway. The call and the result are logged, never the full arguments, and the log is kept for 90 days. The log is reviewed in the weekly ops check. - Local servers: a local server the client starts runs with the client's privileges. The policy says the SDK's STDIO transport, which does the starting, "is not a sandbox". Local STDIO servers run inside a container by default. Remote HTTP is used only through the gateway, with authentication. What the client receives The server inventory and the approved-server list land in the client's AI register. This work is part of the two-week AI readiness and risk assessment. When I review this entry Last reviewed: 7 October 2026. I review this entry again on every new revision of the specification and on any new class of CVE.glossaryhttps://meshin.co/glossary/agentic-workflowhttps://meshin.co/glossary/agentic-workflowAn agentic workflow is a task where one or more AI agents plan steps, call tools and choose the next move without a person's approval.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It comes up the moment a pitch or a product description says "agent" instead of "assistant". A security reviewer's next question is almost always what the agent can do without asking first. The reviewer asks because that is where the real exposure sits, not the model choice. A board hears "agentic" and correctly hears "this thing takes actions on its own." That is a different risk conversation than a chatbot that only produces text. What to do about it List every action an agent can take, not just what it can say, and sign off on each as a separate risk. Set a real limit on what it can do without a person confirming first, especially anything that spends money, touches a customer record, or sends something external. Log every tool call, so a bad outcome traces to a specific decision. Evals belong here: test the whole action chain, not just the model's replies.glossaryhttps://meshin.co/glossary/ai-governancehttps://meshin.co/glossary/ai-governanceAI governance is the decisions, roles and controls a company uses to manage the risk of the AI systems it builds or buys.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up An insurer asks who owns AI risk before writing a policy. A board member reads about an AI failure elsewhere and asks what would happen here. An investor's due-diligence checklist now has a line for it too. Write down who is responsible for each system, and who would notice if it started producing worse answers. What to do about it Start with a one-page register: every AI system in use, who owns it, what data it touches, and whether customer data leaves the building. Assign one named owner per system, not a team. Add a single sign-off step before a new system reaches production. Map what you already do against the NIST AI RMF or ISO/IEC 42001. Do this so you have a recognised structure to point at, not to get certified immediately.glossaryhttps://meshin.co/glossary/ai-impact-assessmenthttps://meshin.co/glossary/ai-impact-assessmentAn AI impact assessment is a written check, before a high-risk system goes live, of who it affects and whether they can challenge its decision.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It comes up wherever an AI system's output changes the offer a real person gets. That includes a loan, a job interview, an insurance price or a public benefit. A board hears about it once a pilot nears launch and legal asks who reviewed fairness before customers saw it. Procurement teams increasingly expect a written answer rather than a verbal assurance, since the assessment itself is what a regulator can ask to see. What to do about it Name the specific groups the system could disadvantage before launch. Use the actual decision it makes and who it makes it about. Write down the mitigation for each risk identified, and who checked that the mitigation actually works rather than just exists on paper. Before a customer's legal team asks, I flag which systems need this specific assessment inside the AI readiness and risk assessment.glossaryhttps://meshin.co/glossary/ai-management-systemhttps://meshin.co/glossary/ai-management-systemAn AI management system is the recurring set of policies, roles and reviews a company runs to govern its AI, not a one-off risk assessment.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A procurement questionnaire increasingly asks for an AI management system by name, not a risk assessment for one product. This happens because a buyer wants proof that governance survives a change of staff. A board hears the phrase once a competitor announces ISO/IEC 42001 certification and asks whether the company should follow. The honest answer is usually that the certificate matters less than the structure behind it, since an unread policy is worth little more than none. What to do about it Write the policy in one page an engineer would actually follow, not a document written for an auditor. Name an owner for the system as a whole, not just for individual products. Set a fixed date to review the register rather than waiting for a customer to ask. I score exactly this structure against ISO/IEC 42001 in the two-week AI readiness and risk assessment. So the gap list is evidence rather than a guess.glossaryhttps://meshin.co/glossary/ai-registerhttps://meshin.co/glossary/ai-registerAn AI register is a company's own inventory of every AI system it builds, buys or uses, naming its owner and how risky it is.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is usually the first document a procurement team or an investor's checklist asks for, and the first one a company discovers it lacks. A security review cannot get past "what AI systems touch our data" without one. A board asking about AI risk gets a shorter conversation once a real list sits in front of it. For high-risk systems, the EU AI Act goes further: Article 71 requires joining a public EU database. What to do about it Build a spreadsheet before anything more elaborate. Use one row per system, with columns for name, what it does, vendor or model, data it can see, owner and risk tier. Interview engineering, marketing, finance and support instead of relying on a self-reported survey. That is how tools added outside a formal process get missed. Review the list on a fixed schedule, since a stale register looks worse in review than admitting you lack one. Quarterly is reasonable.glossaryhttps://meshin.co/glossary/conformity-assessmenthttps://meshin.co/glossary/conformity-assessmentA conformity assessment proves a high-risk AI system meets the EU AI Act before sale. Either the provider or an outside body runs it.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up An investor or a board asks how a company knows its AI system is compliant. A vague assurance is not the same as pointing to a completed assessment and a signed declaration. A procurement team increasingly asks to see evidence the assessment happened at all, rather than taking a compliance claim on trust. It also surfaces at the worst time, during a late-stage system change, when nobody planned for a second assessment. What to do about it Work out early, before the system is built, which assessment route applies. That matters because a notified-body review takes far longer to arrange than an internal one, and you cannot rush it at launch. Keep the assessment evidence alongside the technical documentation it depends on, not in a file only one person can find. Mapping each system to its likely route is part of the AI readiness and risk assessment done before a deadline forces the decision.glossaryhttps://meshin.co/glossary/data-classificationhttps://meshin.co/glossary/data-classificationData classification is labelling data by sensitivity, such as public, internal or restricted, before deciding what may reach an AI tool.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is the first practical question underneath any AI acceptable-use policy. Can this go into that tool? Nobody can answer that until someone has labelled what this actually is. A security reviewer asks for the classification scheme by name, not as an abstract principle. The scheme is what turns a policy from a statement of intent into something an employee can actually follow on a Tuesday afternoon. What to do about it Keep the scheme small. Three or four tiers is enough for most companies, and a scheme nobody can remember gets ignored the same as none. Map every AI tool in the register to which tiers may reach it. Make the most important rule explicit: customer data and secrets never go into an unclassified tool. The AI Governance Starter Kit already includes this table, mapped to what may reach a vendor.glossaryhttps://meshin.co/glossary/eu-ai-acthttps://meshin.co/glossary/eu-ai-actThe EU AI Act is an EU regulation that sorts AI systems into risk tiers and sets legal obligations, heaviest for high-risk systems.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It comes up the moment a company has, or wants, a customer in the EU, regardless of where it is based. A customer's legal team asks which risk tier your product falls into before they sign, because their own exposure depends on your answer. A board asks about it once a competitor gets fined, or a customer raises it at renewal. The Act follows the AI system's users, not the provider's registered address. What to do about it Work out which risk tier each AI system falls into. Most products used inside a normal business are not high-risk. A few categories, hiring and credit among them, almost always are high-risk and deserve a real legal read. For anything near the high-risk category, start the paperwork now: a risk assessment, a named oversight point, and technical documentation. For everything else, keep the register entry current, so the answer is a lookup, not a scramble.glossaryhttps://meshin.co/glossary/evalshttps://meshin.co/glossary/evalsEvals are repeatable tests that score an AI system's output against fixed examples, run before release and after every change.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A security reviewer or a technical board member asks the same question they would of any release process. What stops a bad change from reaching customers? For a normal codebase, the answer is a test suite. For an AI feature, the honest answer is either an eval suite or "we check by hand." That second answer does not hold up once a product has more than a couple of prompts. What to do about it Write down twenty to fifty real cases the system must handle correctly. Draw them from actual support tickets or usage, not invented examples, and include a few you know are hard. Score each case automatically where you can, and by a human reviewer where you cannot. Track the pass rate over time rather than treating one run as final. Run the suite before every prompt or model change ships.glossaryhttps://meshin.co/glossary/guardrailshttps://meshin.co/glossary/guardrailsGuardrails are code checks on what a model responds to, what it can say and what it can do, not rules typed into a prompt.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Asking what guardrails a system has is one of the shortest, most common questions in a security review. It is a hard one to answer honestly if the only guardrail is the model's own training and good manners. A board hears it as a proxy for a bigger question. What is the actual worst thing someone could trick this system into doing, and what stands between that action and a real customer? What to do about it Write guardrails as rules the code enforces, not text pasted into a prompt. Test each one against an input designed to defeat it, not a well-behaved example. Put a real check in front of any action that spends money, changes a record, or sends something external. That way a failure blocks the action instead of completing it. The 90-Day Production Sprint builds these checks into the workflow itself, not as a retrofit after an incident.glossaryhttps://meshin.co/glossary/hallucination-ratehttps://meshin.co/glossary/hallucination-rateA hallucination rate is the share of a model's answers that are confidently wrong, measured against real questions with known correct answers.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A board asks this before it asks about model architecture or vendor choice. It turns "is the AI any good" into a number anyone can track quarter to quarter. A company that cannot answer with one, measured on its own real use cases, is really saying "we do not know." That reads differently in a board pack than an honest figure with the method stated plainly. What to do about it Measure the rate on the eval suite's real cases, not a generic public benchmark. Behaviour on general trivia says little about a specific product's actual questions. Track the number after every prompt or model change, the way a team tracks an eval pass rate. Do not measure it once and assume it holds. The 90-Day Production Sprint puts this measurement inside continuous integration, so a regression blocks a release.glossaryhttps://meshin.co/glossary/high-risk-ai-systemhttps://meshin.co/glossary/high-risk-ai-systemA high-risk AI system is one the EU AI Act puts under its heaviest duties, through product-safety law or use cases like hiring or credit.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is the first question every other AI Act obligation depends on. A customer's legal team or an investor's due diligence checklist asks it before anything else about the system. A board hears it phrased more simply, as "are we in the category that gets the heavy paperwork, and who decided." Getting the classification wrong either way has a real cost, either missed obligations or needless process on a system that never required it. What to do about it Run the classification test on each system separately, not on the company as a whole. One product can be high-risk while another, built the same month, is not. Write the decision down, including the reasoning for a not-high-risk conclusion, since an authority can ask to see it later. This classification is exactly what the AI readiness and risk assessment produces for every system in the inventory, not just the ones already suspected.glossaryhttps://meshin.co/glossary/human-in-the-loophttps://meshin.co/glossary/human-in-the-loopHuman-in-the-loop means a person reviews or can stop an AI system's output before it takes effect, not the system acting alone.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It comes up whenever an AI system's decision touches something real: a loan, a job application, a support case, a medical or safety-adjacent judgement. A customer's legal team wants to know whether a person can catch and correct a bad output before it reaches someone affected. That is not the same as a person being "involved" in some vague sense. A board asks after seeing an automated system make a costly call nobody had reviewed. What to do about it Decide, system by system, where full automation is fine, a wrong answer that costs little and is easy to reverse. Decide, too, where a person must review before anything takes effect. Where a person is in the loop, give them enough time and context to catch a bad output. A rubber-stamp screen that exists only to tick a box does not count. Record which category each system falls into in the AI register.glossaryhttps://meshin.co/glossary/human-oversighthttps://meshin.co/glossary/human-oversightHuman oversight is the EU AI Act duty that a person assigned to watch a high-risk system can actually understand it and stop it.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It differs from asking whether a human is in the loop. That is a design question about where a person sits in a workflow. Human oversight is a legal test of whether that person can catch a bad output and has the time, context and authority to stop it. An auditor tests this by asking what the overseer would do in a specific bad case, not whether a review step exists on a diagram. What to do about it Name the specific person or role authorised to halt each high-risk system, not a team. Check that the person has time per case to evaluate output rather than approve on reflex. Train that person specifically on automation bias. A rushed or over-trusting reviewer defeats the requirement even when the process looks correct. The Fractional CAIO Retainer includes reviewing who watches each system, and whether they could catch a failure this week.glossaryhttps://meshin.co/glossary/iso-iec-42001https://meshin.co/glossary/iso-iec-42001ISO/IEC 42001 is the first international, certifiable standard for the management system a company runs to govern its AI.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A procurement team building a vendor shortlist asks for it by name. A board that already understands ISO 27001 reaches for the same mental model, and asks whether an AI equivalent exists. Because it is a certifiable standard, not a public framework, it carries more weight in a formal audit than a self-written policy. That is why a customer's legal team may put it on a checklist before reading what is in it. What to do about it Full certification is a real project with an external auditor, and most companies at seed to growth stage do not need it yet. What is worth doing now is running the standard's own structure without the audit. The structure is a documented risk-assessment method, an AI system inventory, and a review of that inventory on a fixed schedule. That gives you "built to the same structure, without the certificate," a stronger position than silence or an unsupported claim. Gap assessment A gap assessment compares what your company does today with what ISO/IEC 42001 asks for, and lists the difference. Take the requirements one by one, mark each as in place, partly in place or missing, and note the evidence you can show for it. Rank the missing ones by what a customer or auditor would ask about first. The result is a work list, not a certificate and not a pass or fail grade. The AI Readiness & Risk Assessment includes a gap list against this standard.glossaryhttps://meshin.co/glossary/llm-gatewayhttps://meshin.co/glossary/llm-gatewayAn LLM gateway is a single service every call to a language model passes through, for authentication, logging, rate limits and content filtering.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A security questionnaire almost always asks how the company controls and logs access to the model provider. "Each team manages its own API key" is a poor answer. A board or customer asks a version of the same question after a well-publicised leak elsewhere. In that leak, a prompt carrying sensitive data reached a third-party model unlogged. Without a gateway, nobody can produce every prompt sent to a vendor last month. What to do about it Put one gateway in front of every model call before adding a second application that talks to a model, not after. Route all API keys through it rather than into individual codebases, and log every request and response. Redact anything that looks like a customer identifier or a secret before it leaves. Solid open-source and hosted options already exist, so this is rarely worth building in house. The gateway as a governance control A written policy says what staff may do with a model. A gateway is the control that enforces it, because every model call passes through one place where the policy runs. It decides who may call which model, strips sensitive data before it leaves, applies rate limits, and logs each request and response. That log is the evidence a security questionnaire asks for: it shows the policy ran, not only that it exists. The limit is coverage: a gateway controls only the calls that go through it, so an application that calls a vendor directly sits outside the control. The LLM Gateway Governance Config gives a policy file format for one.glossaryhttps://meshin.co/glossary/model-cardhttps://meshin.co/glossary/model-cardA model card is a short document that a model's maker publishes about the model's intended use, its performance and where not to use it.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Procurement asks a model vendor for it directly once evaluating more than one option. A card makes two vendors comparable on the same axes, rather than on whatever each chose to advertise. A technical due-diligence review reads the limitations section specifically. That is where a vendor is most likely to have been honest about where the model actually struggles. What to do about it Ask every model vendor for their card before signing. Read the limitations section before the headline numbers: the numbers are chosen by the vendor, and the limitations rarely are. If a company fine-tunes or wraps a base model itself, write a short card of its own. Describe what changed and what the company tested. The vendor questionnaire this request belongs in is one of the four documents in the AI Governance Starter Kit.glossaryhttps://meshin.co/glossary/model-provenancehttps://meshin.co/glossary/model-provenanceModel provenance is a traceable record of where a model comes from - its base model, its training data, and the licence covering both.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A customer's legal team asks it once a product's output could plausibly end up in something they publish, resell or use to make a decision. They inherit whatever rights problem the underlying model carries. It also comes up quietly in procurement: the model actually behind a feature can differ from what the vendor's marketing page implies. That gap widens once a vendor swaps providers without telling anyone. What to do about it Ask every model vendor what data trained the model, or where its training-data summary sits if the vendor owes one. Ask what licence covers the weights and output. Record the answer in the AI register next to that system, not in an email thread nobody can find during a review. The AI readiness and risk assessment reads the actual vendor list, not a list a company describes from memory.glossaryhttps://meshin.co/glossary/nist-ai-rmfhttps://meshin.co/glossary/nist-ai-rmfThe NIST AI Risk Management Framework (AI RMF) is a voluntary US framework for managing AI risk across a system's whole lifecycle.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It comes up in almost every vendor security questionnaire, and in board packs once a company runs more than one AI system. A customer's risk team wants a framework they recognise, not a bespoke description of your process. They want it because it lets them compare you against every other vendor they review. A board wants the same thing for a different reason: a structure to ask questions against, rather than trusting that engineering thought of everything. What to do about it Read the four functions once, properly, rather than skimming a summary. Map what you already do against GOVERN, MAP, MEASURE and MANAGE, and write down the gaps honestly. You do not need to implement all of it before you can talk about it. A short document lists what you have, your review step, and what you still owe against each function. That document beats a claim of full compliance with nothing behind it.glossaryhttps://meshin.co/glossary/observabilityhttps://meshin.co/glossary/observabilityObservability means seeing exactly what a user asked a live AI system, what it did and what it answered, for any one case.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up A customer or an internal investigation asks: show me exactly what happened in this one case. A system with only aggregate metrics cannot answer. That is precisely the gap a security review is testing for when it asks about monitoring. It also comes up after a customer complaint that a specific answer was wrong. The honest response depends entirely on whether that exact exchange was ever recorded. What to do about it Log the full input, every step the system took including tool calls, and the output for every real request, not a sample. Keep those logs long enough to support an investigation. Make sure any one case can be pulled up by its own reference, rather than only appearing inside an average. This logging, plus a cost-per-outcome view, ships from the first release in the 90-Day Production Sprint.glossaryhttps://meshin.co/glossary/post-market-monitoringhttps://meshin.co/glossary/post-market-monitoringPost-market monitoring is the EU AI Act duty to keep collecting real-world data on a high-risk system after it ships, not just before.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Does anyone keep watching this system, or was it tested once and left alone? That is the specific question a customer's security team or a regulator asks after any AI failure story in the press. A board hears it as reassurance that a problem would surface through a defined process rather than a customer complaint reaching the news first. Providers who can only describe pre-launch testing, and nothing after, usually have no answer. What to do about it Write the monitoring plan before launch, since a plan invented after a problem appears is not the same thing. In the plan, say what you measure, who reviews it and how often. Build a route for deployer-reported issues to reach the provider. A monitoring system that never hears from the people using it day to day is monitoring very little. The Fractional CAIO Retainer I run keeps this review on a fixed schedule, not only when a customer complains.glossaryhttps://meshin.co/glossary/provider-vs-deployerhttps://meshin.co/glossary/provider-vs-deployerProvider and deployer are EU AI Act roles - a provider builds or brands a system, a deployer uses it, and the two owe different duties.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It surfaces in a contract negotiation once both sides realise the label matters more than expected. A provider owes technical documentation and a conformity assessment, while a deployer mainly owes human oversight and monitoring. A board hears about it when a vendor's contract quietly assigns the company duties it assumed the vendor carried. Getting the role wrong can leave a company holding an obligation nobody budgeted for. What to do about it Run the provider-or-deployer test per system, not per company. Rebranding one vendor's model can make a company a provider for that product while it stays a deployer for everything else it merely uses. Write the answer into the AI register alongside the risk tier, since a security questionnaire will eventually ask for both. The Fractional CAIO Retainer is where I answer this kind of question inside a live negotiation. Deployer obligations checklist Article 26 of the EU AI Act sets these duties for a deployer of a high-risk AI system. They apply to high-risk systems only. The provider carries a separate set of duties, and public authorities and some biometric uses carry further duties in the same Article. - Use the system as the provider's instructions for use say. - Assign human oversight to people who have the competence, training, authority and support to do it. - Make sure the input data you control is relevant and representative for the system's purpose. - Monitor the system against those instructions. If you have reason to think it presents a risk, tell the provider, importer or distributor and the market surveillance authority without undue delay, and suspend its use. - Report a serious incident at once, to the provider first. - Keep the logs the system generates, as far as you control them, for at least six months unless other law says otherwise. - If you are an employer, tell the workers' representatives and the affected workers before you use a high-risk system at work. - Tell people when a high-risk system listed in Annex III makes or helps make a decision about them. - Use the provider's information for your data protection impact assessment where one is required. - Cooperate with the competent authorities.glossaryhttps://meshin.co/glossary/retrieval-augmented-generationhttps://meshin.co/glossary/retrieval-augmented-generationRetrieval augmented generation, or RAG, has a model look up relevant passages at answer time instead of relying only on its training.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Procurement asks "is this RAG, or did you train on our data," because the two have different data-handling implications. RAG typically sends only retrieved snippets to the model at query time, rather than baking a customer's content into the model's own weights. It also comes up once someone questions accuracy. A wrong answer usually traces to a retrieval problem, not a flaw in the model itself. What to do about it Control access at the document-store level, not only at the chat interface. RAG will surface anything in the index to anyone who can ask the right question, regardless of who is meant to see it. Treat the document store itself as a data-classification boundary. Check what happens when a document containing hidden instructions ends up inside it. That exact scenario is one of the checks in the 90-Day Production Sprint.glossaryhttps://meshin.co/glossary/serious-incident-reportinghttps://meshin.co/glossary/serious-incident-reportingSerious incident reporting is the EU AI Act duty to tell a regulator, fast, when a high-risk system causes real harm or a rights breach.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It surprises companies who assume that deploying a high-risk system is a one-time compliance exercise. That is the same surprise a data-breach notification law gives a company that has never had to report one before. A board's real question is usually simpler. If something goes badly wrong, does the company already know who calls the regulator? The alternative is a decision made live, under pressure, by whoever happens to be in the room. What to do about it Decide in advance, in writing, who has the authority to judge that an incident is serious enough to report. Avoid leaving that call to whoever notices the problem first. Preserve the system's state at the time of the incident for investigation, instead of immediately patching it away. The Fractional CAIO Retainer makes me the named point of contact for this kind of question, answered before it is urgent.glossaryhttps://meshin.co/glossary/shadow-aihttps://meshin.co/glossary/shadow-aiShadow AI is any AI tool staff use for company work without IT or security's knowledge, from an app to a browser extension.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is usually the first uncomfortable finding of a readiness assessment, and nobody did anything malicious. The register a company thought was complete turns out to have gaps. That happens the moment someone checks browser extensions and expense reports, instead of asking teams to self-report. A customer's security team asks about it, having had a bad experience before. A board hears one checkable question: could an employee be pasting customer data into a public tool right now? What to do about it Look rather than ask: check browser extension inventories, expense reports for AI subscriptions, and API billing for model providers nobody remembers approving. Publish a short list of approved tools, and a fast route to request a new one. The main driver of shadow AI is an approval process slower than the problem it solves. Fold anything found straight into the AI register, rather than treating discovery and governance as separate steps.glossaryhttps://meshin.co/glossary/sub-processorhttps://meshin.co/glossary/sub-processorA sub-processor is a vendor an AI provider uses behind the scenes to handle a company's data, and GDPR requires permission before it does.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is a routine line on a security questionnaire: "list your sub-processors." It is also a revealing one. Teams build most AI features on someone else's model, which makes a sub-processor almost guaranteed rather than an edge case. A buyer who skips the question is signing a contract blind. They will not know where their data actually goes once it leaves the vendor's own systems. What to do about it Ask every AI vendor for its sub-processor list, and how it notifies customers of a change. Then check honestly: does the notice give a real chance to object, or just a record that it happened? Add the answer to the AI register entry for that vendor, next to the data classification of what reaches them. The Fractional CAIO Retainer is where I check vendor contracts for this gap before a renewal.glossaryhttps://meshin.co/glossary/technical-documentationhttps://meshin.co/glossary/technical-documentationTechnical documentation is the dossier a provider keeps on a high-risk AI system - its purpose, design, data, performance and monitoring plan.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is different from a marketing spec sheet or an engineering wiki page. A regulator or notified body wants the specific content the Act lists, not a general description of the product. It also comes up in procurement due diligence, where a buyer of a high-risk system sometimes asks to see excerpts before signing. A vendor who can produce none of it has told you something. What to do about it Start the document on the first day of build, recording design decisions as you make them. Reconstructing the reasoning behind a choice months later is far harder than writing it down at the time. Version it alongside the system itself, so the documentation for a given release actually matches what shipped. The AI Governance Starter Kit covers the register and policy this documentation builds on, ahead of the deeper regulatory detail.glossaryhttps://meshin.co/glossary/prompt-injectionhttps://meshin.co/glossary/prompt-injectionPrompt injection is text, typed directly or hidden in a document a model reads, that gets the model to follow it as an instruction.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up It is the first thing a security reviewer probes on any AI feature that reads outside content. That means a webpage, an uploaded file, an email, or a customer's own message history. The concern is not academic. A model that can also send an email, issue a refund or query a database turns a successful injection into something already done. It is no longer just an embarrassing reply. What to do about it Never let a model's output directly trigger a sensitive action without a check enforced in code. Keep the model's own permissions to the smallest set it needs. Treat anything the model reads from outside the conversation as untrusted input, the way a web application treats a user-supplied string. Evals for exactly this kind of attack belong in the same pipeline that gates every other change. That is how I structure the 90-Day Production Sprint.glossaryhttps://meshin.co/glossary/red-teaminghttps://meshin.co/glossary/red-teamingRed teaming is deliberately trying to break an AI system the way an attacker would, before they do, to find the failure nobody tested.Tue, 08 Sep 2026 00:00:00 GMTWhy it comes up Boards and security reviewers increasingly ask for it by name, rather than accepting "we ran evals" as a full answer. An eval suite built by the same team that built the system tends to test what that team already expected to go wrong. It matters more, not less, once a system can take actions or read outside content. A missed failure then moves from a bad reply to a completed action. What to do about it Budget real time, not an afternoon, for someone to actively try prompt injection, data extraction and off-limits requests. Do it against the actual live system, not a sanitised demo. Write down exactly what broke, and fix the underlying guardrail, not just the one example that happened to get tried. I treat this as part of shipping in the 90-Day Production Sprint, folding findings back into the eval suite before launch.glossary