AI compliance in plain English.

The EU AI Act is a law that sets rules for artificial intelligence based on the risks it creates. The higher the risk to people's rights or safety, the more responsibility falls on the organizations building or using it.

Here is the framework in five sentences:

1. Some uses are prohibited because they pose unacceptable risks, such as certain manipulative practices and forms of social scoring.
2. High-risk systems face stricter requirements, including risk management, documentation, human oversight, and recordkeeping.
3. Certain AI interactions must be transparent, so people know when they are interacting with AI or seeing certain AI-generated content.
4. General-purpose AI models have their own obligations, with additional requirements for models that pose systemic risks.
5. The rules take effect in stages, so your obligations depend on your role, your system, and the applicable implementation date.

In plain English Start with what your AI actually does, who it affects, and the role your organization plays. Not every AI tool has the same obligations.

A useful first step isn't to memorize the whole law. It's to inventory the AI you use and ask: what decision does this support, and who could be harmed if it gets that decision wrong?

Read the official EU AI Act overview before relying on an implementation deadline. A five-sentence summary is a starting point, not a compliance assessment.

AI governance is the work of making sure artificial intelligence is used responsibly, with clear accountability and evidence to back it up. It is not just a technology problem. It is a compliance problem, too.

That is what drew me in.

My background is in federal grants compliance: eligibility checks, reporting requirements, and the steady work of making sure a record tells the same story as the process behind it. ORR reporting taught me that good intentions are not a substitute for good documentation.

Now I see organizations asking new questions. Who approved this AI tool? What data went into it? What happened when its output was wrong? Can we reconstruct the decision six months later?

The vocabulary is different. The discipline is familiar.

Key takeaway An audit trail is an audit trail, whether it's grant dollars or model outputs.

I also work with systems, databases, Knack, and SQL. That matters because a framework only becomes useful when you can translate it into fields, workflows, checks, and records people can actually maintain.

As a doctoral student in Information Technology in Education at the University of Nevada, Reno, I am thinking about where these questions meet learning, institutions, and public trust.

This blog is where I will work through them — in plain English, one practical idea at a time.

An AI audit needs evidence of how a system was selected, used, monitored, and corrected. The most useful evidence is created during the work — not assembled from memory when someone asks for it.

Federal grants compliance made that lesson concrete for me.

Document the decision, not just the result

A completed report is not the whole record. You also need the criteria, the person responsible, and the source material behind it. With AI, the same principle applies: record what the tool was used for, who reviewed its output, and what happened next.

Check eligibility before moving forward

In grants work, you check whether an activity meets the requirements before treating it as allowable. For AI, ask whether the proposed use is appropriate for the data, the people affected, and the rules that apply. A convenient tool is not automatically an acceptable one.

Make reporting repeatable

Clear definitions and consistent records make reporting useful. If every team means something different by “reviewed,” your audit trail will be difficult to trust.

Key takeaway Build the record into the workflow. If documentation depends on someone remembering later, you already have a gap.

The technology will keep changing. Clear responsibilities, consistent checks, and a record you can reconstruct remain a strong place to start.

Some of the most valuable work I've done is requirements gathering: sitting with people, learning what a system actually needs to do, writing it down before anyone shops for software. The order matters. Requirements first, tool second. Teams that shop first end up bending their work around whatever they bought.

AI adoption is running this backwards everywhere I look.

A team hears about a tool, buys it, and then hunts for problems to point it at. Six months later they're maintaining an expensive solution in search of a problem — and the actual needs, the ones a requirements session would have surfaced in a week, are still unmet.

Don't automate chaos. And don't shop before you know what you're shopping for.

Start where my systems work always started: what decision are we trying to improve? What does good look like? What are the constraints — the data, the rules, the people affected? Write that down first. Then evaluate tools against it.

Requirements first, tool second. It's slower for a week and faster for years.

I explain frameworks; I don't give legal counsel.

My rule for AI is simple: don't automate chaos. It applies to data first.

Messy collection. No retention schedule. Mystery vendors holding copies of everything. Datasets nobody documented. That's chaos, and an AI system won't fix it. It will scale it — faster collection of the wrong things, longer retention of what should've been deleted, confident decisions built on shaky ground.

The order matters. Govern the data first: know what you have, collect less, keep it clean, delete on schedule, write it down. Then bring in the AI.

Do it the other way around and you'll spend twice the money to learn what the tidy teams already knew.

Don't automate chaos. Especially not data chaos.

I explain frameworks; I don't give legal counsel.