Disclaimer: This article documents my personal exploration of AI governance architecture and regulatory concepts using hypothetical examples as of May 2026. Nothing in this post constitutes legal advice, regulatory advice, compliance certification, or a guarantee of legal or regulatory conformance. AI governance requirements vary by jurisdiction, sector, role, system design, and use case. Consult qualified legal and compliance professionals before making governance decisions. NosisTech LLC accepts no liability for outcomes arising from use of this content.
Most AI governance talk is abstract. Everyone talks about risk, compliance, regulation, and accountability, but they rarely show what the first working layer could look like. I wrote this to show a simpler and safer idea: not an agent that decides legal status, but an intake desk that organizes facts before qualified review. The result is a small educational architecture that helps explain what a governance workflow could collect, flag, and route.
What This Agent Does
This agent looks at a hypothetical AI system description.
The fictional example is a hiring-screening assistant. It scores job applications and recommends which candidates should be interviewed. In a real company, that kind of system would require careful review because it may influence access to work.
The agent does not say, “This system is legally high risk.”
It says something safer and more useful:
This hypothetical system shows review signals. Here are the areas that may need qualified legal or compliance review. Here is the evidence a governance team should collect before anyone makes a real decision.
That difference matters. A legal classifier pretends to give an answer. An intake agent helps people ask better questions.
The Intake Desk
Think of this agent like the front desk at an airport.
The person at the desk does not decide every immigration, security, customs, or legal question. Their job is to look at your documents, notice what kind of review you may need, and route you to the right counter.
That is what this build does for AI systems.
It does not replace lawyers. It does not certify compliance. It does not promise that a system is safe. It looks at a hypothetical AI use case and says, “Before anyone makes a serious decision, collect these facts.”
That is the practical heart of AI governance.
A company does not only need to know which model it uses. It needs to know what the whole AI system does. That includes the model, the workflow, the data, the vendor, the human reviewer, the affected people, the logs, the permissions, and the business decision being influenced.
If a company uses a third-party SaaS AI tool, the model may be hosted somewhere else. That does not mean the company can ignore governance. It still needs vendor evidence, internal controls, and a clear understanding of what the system can actually do.
Vocabulary You Need
AI system: In this post, an AI system means more than the model. It includes the model, the data, the software workflow, the people using it, the vendor if one exists, the decisions it influences, and the controls around it.
Review signal: A review signal is not a legal conclusion. It is a warning light that says, “This area deserves closer review.”
Annex I: In the EU AI Act context, Annex I relates to AI used in certain regulated products or safety components. A simple analogy is a machine part in a factory line. If the AI affects product safety, the review is not only about the AI model.
Annex III: Annex III relates to sensitive use areas, such as employment, education, essential services, law enforcement, migration, justice, and similar contexts. These are areas where AI may affect important opportunities or rights.
Human oversight: Human oversight means more than putting a person near the system. The real question is what the human can see, understand, stop, override, or change.
What This Is Not
This is not legal advice.
This is not a compliance product.
This is not a certification engine.
This is not a final EU AI Act classifier.
This is not a new isolated AI governance framework.
This is a small educational intake layer. It demonstrates how an AI governance workflow could collect facts and flag review areas before qualified legal, compliance, security, and business teams make real decisions.
Why Build This
I keep seeing AI governance discussed as if the only options are legal memos or giant enterprise platforms. That misses the architecture.
Before a company buys a governance platform, someone still has to understand the shape of the workflow. What facts matter? Who is affected? What decision does the system influence? What can the human reviewer actually change?
I built this because I wanted the smallest visible version of that pattern. Not a legal determination. Not a compliance shortcut. A working intake desk that shows how rules, evidence collection, and model explanation can fit together without pretending the AI is a lawyer.
What Actually Happened
What surprised me:
The safer version did not need more code. It needed clearer boundaries, better wording, and a shift from classification to evidence gathering.
What I would change next:
I would separate legal content updates from code structure from the beginning. The law can change, but the intake architecture can stay stable.
Why this matters:
In governance work, complexity can create false confidence. A smaller intake demo makes the limits clearer, which is exactly what I want when working near legal and regulatory topics.
The Architecture: How It Works
The architecture has five parts.
First, the agent starts with a hypothetical AI system description. In this build, the fictional system is a hiring-screening assistant.
Second, the rule layer looks for review signals. For example, words like hiring, job application, CV, recruiter, and candidate point toward employment and worker management review.
Third, the evidence checklist asks what a real governance process would need to know. It asks about purpose, deployment context, organizational role, data touched, people affected, human control, logs, and vendor evidence.
Fourth, the model writes a cautious summary. The model does not decide legal status. It explains the review flags in plain English.
Fifth, the report prints the result with a strong disclaimer.
The key design choice is this: the model explains, but the code controls the review flags. That keeps the workflow inspectable.
A useful analogy is a building inspection checklist. The checklist does not make the building safe. It helps the inspector know what to examine. This agent works the same way.
The Core Components
The Hypothetical System Description
The agent starts with a fictional business system. That matters because governance does not start with code. It starts with facts about the use case.
The Review Area Table
The rule table maps ordinary phrases to review areas. It does not make a legal conclusion. It says, “This area deserves attention.”
The Evidence Checklist
The checklist is the practical part of the build. It asks what a real team should collect before qualified review.
The Model Summary
The model turns the review result into readable language. This is useful because governance reports need to be understandable to business people, not only engineers.
The Disclaimer Boundary
The disclaimer appears in the terminal output because the build is legal-adjacent. The article and the agent both make clear that this is an educational demo using hypothetical examples.
The Model-Agnostic Layer
This build uses an OpenAI-style client through a LiteLLM-compatible gateway. LiteLLM is an AI routing layer. It lets the same code call different model providers through one consistent interface.
The model name lives in the .env file, not hardcoded inside the Python file.
That means the same agent can run with:
MODEL_NAME=gemini-flash,deepseek-v4-proThe agent then prints a separate report for each model.
I tested this build with Gemini Flash and DeepSeek v4 Pro. Both models produced usable summaries. Gemini tended to write more detailed paragraphs. DeepSeek tended to be shorter and more cautious.
The important part is that the rule layer stayed stable. The model wording changed, but the review flag remained the same.
What to Watch When You Run It
When you run the agent, look for three things.
First, look at the review flag. In the hypothetical hiring example, both models flagged employment and worker management.
Second, look at the evidence checklist. This is the most important part of the build. It shows that governance depends on facts, not just labels.
Third, compare the model summaries. The models may explain the result differently, but the architecture keeps them inside the same boundary.
This is why the intake pattern is useful. The AI can help explain, but the workflow still exposes what triggered the review.
The Build: Step by Step
DISCLAIMER = (
"Educational demo only. All examples are hypothetical as of May 2026. "
"This is not legal advice, regulatory advice, compliance certification, "
"or a legal status determination. For certainty, consult qualified legal "
"counsel in the relevant jurisdiction. The May 7, 2026 Digital Omnibus "
"on AI is treated here as a provisional political agreement pending "
"formal adoption, not final law."
)What This Code Is Actually Doing
This block creates one reusable disclaimer.
A disclaimer is a boundary statement. It tells the reader what the agent is not doing. In this case, the agent is not giving legal advice, not certifying compliance, and not making a legal status determination.
This matters because the demo touches regulation. The safest design is to make the boundary visible in the code and visible in the terminal output.
DEMO_SYSTEM = {
"name": "Hiring Screen Assist",
"purpose": "Scores job applications and recommends which candidates should be interviewed.",
"data_used": "CVs, employment history, education history, and recruiter feedback.",
"deployment_context": "Used by an HR team before human hiring managers review applicants.",
"provider_context": "Built on a third-party AI service and deployed by the employer.",
"human_oversight": "A recruiter can approve or reject the recommendation.",
"actions_allowed": "Ranks candidates, explains the score, and stores a decision note.",
}What This Code Is Actually Doing
This block defines the hypothetical AI system.
It is fictional, but it is realistic enough to teach the pattern. The system has a name, purpose, data used, deployment context, provider context, human oversight, and allowed actions.
Those fields matter because governance review is not only about the model. It is about the whole system around the model.
REVIEW_AREAS = [
(
"Annex III employment and worker management",
["hiring", "job application", "cv", "employment", "recruiter", "candidate"],
"The system may influence access to work or self-employment.",
),
(
"Annex I product or safety component",
["medical device", "toy", "lift", "machinery", "safety component"],
"The system may be part of a regulated product or safety function.",
),
]What This Code Is Actually Doing
This is the review area table.
A review area table is like a checklist at an inspection desk. If the hypothetical system description contains certain signals, the agent flags the area for closer review.
The important word is “may.” The code does not say the system is legally classified a certain way. It says the system may need qualified review.
def find_review_flags(system):
text = " ".join(system.values()).lower()
flags = []
for area, keywords, reason in REVIEW_AREAS:
matches = [word for word in keywords if word in text]
if matches:
flags.append({"area": area, "matches": matches, "reason": reason})
return flagsWhat This Code Is Actually Doing
This function searches the hypothetical system description for review signals.
It combines the system fields into one text block, makes the text lowercase, and checks for matching phrases. If it finds matches, it records the review area, the matching words, and the reason the area matters.
This is the grounded part of the agent. The output shows what triggered the review flag.
def build_evidence_requests(system, flags):
requests = [
"Document the intended purpose and real deployment context.",
"Identify whether the organization is a provider, deployer, importer, or distributor.",
"Record what data the system touches and who may be affected.",
"Explain what the human reviewer can actually change, not just whether a human is present.",
"Keep logs that show what the system was designed to do, what it could do, and what it did.",
]
if "third-party" in system["provider_context"].lower() or "saas" in system["provider_context"].lower():
requests.append("Collect vendor evidence for hosted models, SaaS tools, and third-party controls.")
if flags:
requests.append("Send the flagged areas to qualified legal or compliance review.")
return requestsWhat This Code Is Actually Doing
This function creates the evidence checklist.
Evidence means the facts a real reviewer would need before making a serious decision. The checklist asks for purpose, context, role, data, affected people, human control, logs, and vendor evidence.
This is where the build becomes practical. A company cannot govern an AI system it cannot describe.
prompt = f"""
Write four short sentences for an educational EU AI Act governance intake demo.
Do not use a numbered list or bullet list.
Do not give legal advice or state a final legal classification.
Say the flags are hypothetical review signals as of May 2026.
Mention that the May 2026 draft guidelines use practical examples, but the examples are not exhaustive and may change.
Mention that human oversight is evidence to examine, not automatic proof of safety.
AI system:
{describe(system)}
Review flags:
{flags or "none"}
Evidence requested:
{evidence}
"""What This Code Is Actually Doing
This is the model instruction.
A prompt is the instruction sent to the language model. This prompt tells the model exactly what role it has: explain the result cautiously, do not give legal advice, do not state a final legal classification, and keep the examples hypothetical.
The phrase about human oversight is important. A human reviewer only matters if they can meaningfully understand, challenge, stop, or change the system output.
def extract_message(response):
if isinstance(response, list):
response = response[0]
if isinstance(response, dict):
return clean_text(response["choices"][0]["message"]["content"])
return clean_text(response.choices[0].message.content)What This Code Is Actually Doing
This helper reads the model response.
Different LiteLLM routes can return slightly different response shapes. One route returned the normal OpenAI-style object. Another returned a list wrapper. This helper handles both.
That keeps the demo stable across providers.
def clean_text(text):
for dash in ["\u2012", "\u2013", "\u2014", "\u2212"]:
text = text.replace(dash, " - ")
text = text.replace("\u202f", " ")
text = unicodedata.normalize("NFKC", text)
text = text.replace("third-partyAI", "third-party AI")
return text.encode("ascii", "ignore").decode("ascii").strip()What This Code Is Actually Doing
This function cleans model text before printing it in Windows PowerShell.
Some models return special Unicode spacing or dash characters. Those characters can crash or make words merge together in a Windows terminal. This cleanup keeps the demo readable and plain.
I kept this small because the goal is not to build a text processing library. The goal is to prevent terminal output from breaking the lesson.
def print_report(model, system, flags, evidence, summary):
print("\nAI System Governance Intake Demo")
print("=" * 34)
print(f"Active model: {model}")
print(describe(system))
print("\nReview result: Needs qualified review" if flags else "\nReview result: No obvious flag in this demo")What This Code Is Actually Doing
This function starts the terminal report.
It prints the active model so I can compare Gemini and DeepSeek in one run. That matters because the same rules can produce the same review flag while different models explain it differently.
The report says “needs qualified review” instead of pretending to decide legal status.
Errors I Hit During This Build
The first issue was documentation. The README contained server-specific SSH details. I removed those and replaced them with generic guidance so no real username, host, IP address, or secret appears in the public repo.
The second issue was a false review signal. The first version flagged education because the hiring example mentioned education history. That was too broad, so I tightened the education keywords to avoid treating every mention of education as an education-system use case.
The third issue was a LiteLLM response shape mismatch. The error said:
AttributeError: 'list' object has no attribute 'choices'That happened because one provider route returned a list wrapper instead of the normal OpenAI-style response object. I fixed it with the extract_message() helper.
The fourth issue was a Windows terminal encoding crash. The error said:
UnicodeEncodeError: 'charmap' codec can't encode characterThat happened because a model returned a special Unicode spacing character. I fixed it by cleaning model output before printing.
The fifth issue was formatting. One Gemini output merged third-party and AI into third-partyAI. I added a tiny cleanup replacement so the terminal output stays readable.
What I Would Do Differently
A production version would not keep regulatory review examples directly inside one Python file. It would separate the rule content from the code so legal and compliance teams could update review guidance without changing the program.
A production version would also keep a source register. That register would track official guidance pages, publication dates, consultation status, and whether a change is final or provisional.
I would also add vendor evidence intake. If a company uses a third-party SaaS AI system, the review should collect vendor documentation, data handling details, security controls, audit logs, and contractual responsibilities.
I would add runtime visibility too. A static intake form is useful, but an agentic system can behave differently during execution. A serious governance layer would need logs that show what the system was designed to do, what it could do, and what it actually did.
I would also treat insurance as a backup plan, not a governance system. Insurance may help pay for the financial damage after an AI incident, but it does not make the system safe, well-documented, or properly reviewed. A company still needs controls, evidence, accountability, logs, vendor review, and qualified legal or compliance review. A company might buy insurance for AI-related risks. That insurance might help cover costs from a lawsuit, breach, regulatory fine, business interruption, or investigation. But insurance does not prove the AI system was governed properly.
It does not answer:
Did qualified legal or compliance people review the use case? What data did the AI touch? Who was affected? Did a human actually review the decision? Could the human override the system? Were logs kept? Was the vendor reviewed? Was the system tested?
What This Means
This build shows that AI governance does not have to start with a giant platform.
It can start with a practical intake desk.
For a founder, operator, or executive, the value is simple. Before asking whether a system is compliant, first ask whether the organization can describe the system clearly.
What does it do? Who uses it? What data does it touch? Who is affected? What decision does it influence? What can the human reviewer actually change? What vendor evidence exists? What logs would explain what happened?
Those questions are not bureaucracy. They are operational clarity.
The agent does not replace experts. It prepares better questions for experts.
That is the architecture worth understanding.
How This Could Affect US, LATAM, and Global Companies
Before going further, this section is hypothetical and educational. It is not legal advice, regulatory advice, compliance advice, market-entry advice, or a determination that any company in the United States, LATAM, Asia, Africa, the Middle East, or any other region is subject to the EU AI Act. The examples below are simplified scenarios meant to explain how cross-border AI governance questions can arise. Any real company would need qualified legal and compliance review based on its jurisdiction, sector, customers, contracts, product design, and actual deployment facts.
In this hypothetical May 2026 example, the EU AI Act matters outside Europe because digital products do not stay neatly inside borders. A company in the United States, Latin America, Asia, Africa, or the Middle East may build an AI system locally, host it locally, and still have EU exposure if the system is placed on the EU market or if its output is used in the EU. The question is not only “where is the company incorporated?” The better question is “where is the AI system being used, who is affected, and does the output reach people or organizations in the EU?”
For a US company, the practical effect could look familiar because many global companies already lived through this pattern with privacy regulation. A SaaS company in California might sell a recruiting tool to customers in Germany, France, or Spain. Even if the engineering team, servers, and leadership are in the United States, the company may still need to prepare evidence about the AI system because the product is being offered into the EU market. The simple analogy is exporting food, medicine, or electronics. In many regulated industries, the destination market’s expectations can matter even when the factory, software team, or vendor is somewhere else.
For a LATAM company, the effect could be especially important because many startups and service providers build for international clients from day one. Imagine a Colombian, Mexican, Guatemalan, Brazilian, or Argentine company building an AI customer-support assistant, hiring screener, credit pre-screening tool, or insurance triage tool for a European client. In this hypothetical scenario, the company may not think of itself as “an EU AI company,” but the system’s use case, buyer, affected users, and output destination could still create review questions. That is why an intake agent is useful. It forces the company to ask basic questions before the sales team promises something the governance team cannot support.
This could also affect outsourcing and business-process companies across LATAM. A company may not build the foundation model, but it may configure, deploy, customize, or operate an AI workflow for a client. That matters because governance is not only about the model provider. It is about the whole AI system. If the AI workflow screens resumes, recommends loan eligibility, routes public-service requests, monitors workers, or affects access to important opportunities, a real-world deployment could require qualified review depending on the facts. In simple terms, the company cannot say “the model belongs to someone else” and assume the question is finished.
The same logic could influence companies in Asia, Africa, and the Middle East. A Singaporean AI vendor, an Indian outsourcing firm, a Kenyan fintech startup, a UAE enterprise platform, or a South African HR software company may all need to think about EU expectations if their systems are sold into Europe or if their outputs are used there. This does not mean every AI system becomes high-risk. It means the company may need a way to identify when a system touches sensitive areas, who is affected, which role the company plays, and what evidence would be needed before legal or compliance review.
This is also how regulation spreads without every country copying the exact same law. Large markets may shape global behavior because many companies prefer one strong operating standard over many separate versions. If a company wants to sell globally, it may decide to build internal AI governance around the strictest markets it serves. That does not mean the EU AI Act becomes law in the United States, LATAM, Asia, Africa, or the Middle East. It means the Act may become a practical reference point for customers, investors, insurers, auditors, and regulators who want to know whether a company has serious AI controls.
In the United States, the effect may show up through sector rules, procurement requirements, state-level AI laws, lawsuits, audits, and customer contracts. In LATAM, it may show up through privacy authorities, financial regulators, labor regulators, consumer-protection agencies, public-sector procurement, and multinational client requirements. In Asia, Africa, and the Middle East, it may show up through national AI strategies, data protection rules, cloud procurement rules, banking supervision, telecom regulation, and cross-border vendor assessments. The laws may not all look the same, but the operational questions will rhyme: What does the system do? Who does it affect? What data does it touch? What decision does it influence? What can a human actually change? What evidence exists?
That is why this build avoids pretending to be a legal classifier. A classifier gives people false comfort. An intake desk gives people a better starting point. For a hypothetical global company, a safer first move may be to avoid guessing whether a system is “compliant.” Instead, the practical move is to inventory the system, document its purpose, identify the people affected, understand the vendor chain, collect logs, and route sensitive use cases to qualified review.
The bigger point is strategic. AI governance is unlikely to stay a Europe-only conversation. Even where the EU AI Act does not directly apply, it may influence how enterprises write contracts, how insurers evaluate AI risk, how boards ask questions, how customers evaluate vendors, and how regulators in other regions design their own rules. For builders, that means governance architecture may become more than paperwork. It may become market access infrastructure.
Sources Checked
European Commission, Draft Commission guidelines on the classification of high-risk AI systems: https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems
European Commission, EU agrees to simplify AI rules to boost innovation and ban nudification apps to protect citizens: https://digital-strategy.ec.europa.eu/en/news/eu-agrees-simplify-ai-rules-boost-innovation-and-ban-nudification-apps-protect-citizens
Tools Used
OpenAI Python SDK (Apache 2.0): https://github.com/openai/openai-python
python-dotenv (BSD-3-Clause): https://github.com/theskumar/python-dotenv
LiteLLM (MIT): https://github.com/BerriAI/litellm
NosisTech Agent Engineering (MIT): https://github.com/nosistech/agent-engineering
(c) 2026 NosisTech LLC. Licensed under CC BY 4.0. Use freely, just credit us.