AI Automation Governance and Compliance

AI Automation Governance and Compliance

AI automation governance is the system of policies, responsibilities, controls, and evidence used to keep AI workflows appropriate, accountable, secure, and compliant throughout their lifecycle.

Governance should answer practical questions:

• Which AI workflows are allowed?
• Who owns each workflow?
• What data may it use?
• Which models and tools are approved?
• What actions may it perform?
• Which results need human review?
• How is performance monitored?
• What happens when the workflow fails or changes?
• When should it be paused or retired?

Governance is not only a policy document.

It must be reflected in the workflow itself through permissions, deterministic checks, approval points, activity records, monitoring, and clearly defined stop conditions.

A useful lifecycle is:

Propose Use Case
→ Assess Risk
→ Design Controls
→ Test
→ Approve
→ Operate
→ Monitor
→ Review or Retire

The controls should be proportional to the workflow's impact and autonomy.

A private meeting-summary draft does not need the same governance as an agent that can change customer records or initiate payments.

What AI governance means in automation

AI governance provides a repeatable way to decide how AI may be used.

It covers:

• acceptable use;
• data handling;
• model and provider selection;
• tool access;
• human oversight;
• testing;
• documentation;
• monitoring;
• security;
• compliance;
• incident response; and
• lifecycle ownership.

Traditional governance often assumes that a system follows fixed rules.

AI workflows can vary between runs, interpret unstructured information, use tools, and change behaviour when models or providers change.

This makes operational evidence important.

Organisations need to verify what the workflow actually does, not only what its design document says it should do.

Start with an AI workflow inventory

You cannot govern workflows that no one has recorded.

Maintain an inventory containing:

• workflow name;
• business purpose;
• owner;
• users;
• trigger;
• input sources;
• data categories;
• models and providers;
• tools and destinations;
• level of autonomy;
• review requirements;
• risk classification;
• production status;
• last review date; and
• retirement status.

Include experiments that may affect real data or systems.

Small workflows can become operational quietly when users begin relying on them.

Review the inventory regularly for duplicate, abandoned, unowned, or undocumented automations.

Assign clear ownership

Every AI automation needs a named owner.

The owner should understand:

• the business purpose;
• expected inputs and outputs;
• permitted data;
• models and tools;
• quality requirements;
• review process;
• monitoring metrics;
• failure paths; and
• conditions for pausing the workflow.

Other roles may include:

• business process owner;
• technical maintainer;
• data owner;
• security reviewer;
• privacy or compliance reviewer;
• human approver; and
• incident responder.

Define who makes decisions rather than assuming that responsibility belongs to “the AI team.”

AI output does not remove human accountability.

Classify workflows by risk

Use a simple risk model that considers:

• impact of an incorrect result;
• sensitivity of the data;
• reversibility of the action;
• external visibility;
• number of people affected;
• decision significance;
• level of autonomy;
• tool permissions;
• frequency and scale; and
• difficulty of detecting errors.

A practical set of tiers may be:

Risk classification should influence testing, permissions, documentation, review, and monitoring.

Classify the level of autonomy

Risk also depends on what the workflow can do.

A useful autonomy scale is:

• Observe — reads or summarises information;
• Advise — prepares recommendations or drafts;
• Act with approval — proposes an action that a person must approve;
• Act within limits — performs approved low-risk actions under fixed boundaries;
• Autonomous — chooses and performs actions without case-by-case approval.

More autonomy requires stronger controls.

Increasing autonomy should be a deliberate governance decision based on evidence from testing and production use.

Do not allow a workflow to become more autonomous merely because a new tool was enabled.

Define approved use and prohibited use

An acceptable-use policy should identify:

• approved business purposes;
• approved users;
• approved data categories;
• approved providers and models;
• permitted tools;
• prohibited destinations;
• required review;
• restricted decisions;
• required disclosures; and
• escalation contacts.

Prohibited uses may include:

• entering secrets into ordinary prompts;
• using unapproved public services for confidential data;
• fully automating high-impact decisions;
• creating deceptive or unlawful content;
• bypassing access controls;
• using personal accounts for controlled business workflows; or
• deploying an untested workflow into production.

Policies should be practical enough for users to follow.

Govern data across the workflow

Map the complete data flow.

For each step, record:

• data source;
• data category;
• purpose;
• model or tool receiving it;
• processing location;
• storage location;
• access;
• retention; and
• deletion method.

Apply data minimisation.

A classification workflow usually does not need a complete customer record.

A summary workflow may not need unrelated attachments or historical messages.

Review whether a local model, cloud model, or hybrid design is appropriate.

A local model can keep model processing on the computer, but the workflow is only fully local when every tool, source, and destination also remains local.

Approve models and providers deliberately

Maintain an approved list of:

• cloud providers;
• local model applications;
• model families;
• allowed use cases;
• restricted data types;
• supported features;
• account requirements;
• fallback options; and
• review dates.

Evaluate models using the actual task.

Compare:

• accuracy;
• groundedness;
• structured output;
• latency;
• cost;
• privacy;
• tool use;
• input support; and
• failure behaviour.

A model change can alter workflow behaviour even when the prompt remains the same.

Treat material model or provider changes as controlled workflow changes.

Govern tools and permissions

Tools create operational impact.

Record what each tool can:

• read;
• create;
• change;
• send;
• publish;
• approve; or
• delete.

Apply least privilege.

Separate read and write actions.

Restrict:

• URLs;
• IP addresses;
• file paths;
• ports;
• accounts;
• recipients;
• record types; and
• action scope.

A summarisation workflow should not receive delete or send permissions when it does not need them.

Review tool access after workflow changes and remove unused permissions.

Keep deterministic controls outside the model

Governance requirements should be enforceable.

Use fixed logic for:

• required fields;
• allowed categories;
• numeric thresholds;
• date formats;
• approved destinations;
• duplicate prevention;
• approval requirements;
• retention rules; and
• stop conditions.

The AI model may propose a category, value, or action.

Deterministic logic should decide whether that output is allowed to continue.

Do not rely on a prompt such as follow company policy as the only control.

Policies need technical enforcement where possible.

Add stage-specific approvals

Different lifecycle stages need different approvals.

A workflow may require:

• use-case approval;
• data approval;
• security review;
• privacy review;
• model approval;
• tool-permission approval;
• test approval;
• production approval;
• change approval; and
• retirement approval.

The final operational workflow may also require case-level review.

For example:

AI Draft
→ Validation
→ Human Approval
→ External Send

Record the reviewer, decision, date, version, and supporting evidence.

Approval should not be implied by silence.

Define meaningful human oversight

Human oversight is effective only when the reviewer can influence the outcome.

Reviewers should see:

• original source;
• AI output;
• missing information;
• validation results;
• source references;
• tool activity;
• proposed destination;
• impact of approval; and
• available alternatives.

Reviewers should be able to:

• approve;
• edit;
• reject;
• request information;
• escalate; or
• stop the action.

Use qualified reviewers for legal, medical, financial, employment, safety, security, or other specialist decisions.

Document the workflow

Governance documentation should include:

• business purpose;
• workflow diagram;
• owner and roles;
• approved users;
• input and output definitions;
• data flow;
• model and provider;
• tools and permissions;
• prompt or instruction version;
• validation rules;
• review points;
• evaluation results;
• monitoring metrics;
• known limitations;
• incident procedure; and
• change history.

Keep documentation proportionate.

A low-risk internal summary does not need the same evidence package as a high-impact customer process.

Documentation should be updated when the workflow changes.

Test against defined requirements

Create a representative evaluation set.

Include:

• normal input;
• missing information;
• conflicting information;
• unusual formats;
• every route;
• unsupported requests;
• model failures;
• tool failures;
• denied permissions;
• prompt injection;
• duplicate events; and
• cases requiring human review.

Define acceptance criteria before reviewing the results.

Measure:

• accuracy;
• completeness;
• groundedness;
• format compliance;
• review correction;
• operational reliability;
• privacy controls;
• latency; and
• cost.

Retain enough evidence to explain why the workflow was approved.

Monitor production behaviour

Governance continues after deployment.

Monitor:

• completed and failed runs;
• partial results;
• invalid output;
• reviewer corrections;
• high-impact errors;
• tool activity;
• denied access;
• unusual destinations;
• retries;
• duplicate prevention;
• latency;
• cost;
• source drift;
• model changes; and
• review backlog.

Compare actual behaviour with the approved boundaries.

A workflow that begins using new data, tools, or destinations should be investigated even when the output appears useful.

Governance should rely on operational evidence rather than self-reporting alone.

Define incidents and escalation

An AI incident may include:

• sensitive-data exposure;
• unauthorised tool action;
• harmful or discriminatory output;
• material hallucination;
• incorrect high-impact decision;
• wrong recipient;
• duplicated external action;
• bypassed review;
• compromised credential;
• unapproved provider use; or
• repeated failure outside accepted limits.

Define:

• who receives the alert;
• how the workflow is paused;
• how access is revoked;
• what evidence is preserved;
• who investigates;
• who communicates with affected parties;
• how remediation is approved; and
• when the workflow may resume.

Practise the pause and recovery process.

Manage workflow changes

Changes that may require reevaluation include:

• new model;
• new provider;
• modified prompt;
• new data source;
• new tool;
• expanded permission;
• changed destination;
• new schedule;
• altered risk level;
• new user group; and
• changed business purpose.

Use version control or a clear change record.

Pause important scheduled workflows while changing them.

Rerun the evaluation set.

Obtain the required approval before resuming production.

Small changes can create large behaviour differences in AI systems.

Review third-party and supply-chain risk

AI workflows may depend on:

• providers;
• model files;
• APIs;
• connectors;
• plugins;
• Genes;
• MCP servers;
• workflow templates;
• libraries; and
• external data sources.

Review:

• publisher;
• permissions;
• update process;
• service terms;
• data handling;
• availability;
• security history;
• maintenance status; and
• fallback options.

Test third-party components with synthetic data and limited access.

A trusted platform can still use an unsuitable external extension.

Address fairness and harmful outcomes

Governance should consider whether the workflow affects groups of people differently.

Review:

• training or source-data limitations;
• label definitions;
• false positive and false negative rates;
• language coverage;
• accessibility;
• proxy variables;
• human-review consistency; and
• impact of errors.

Fairness cannot be reduced to one universal score.

Use domain experts and affected stakeholders where appropriate.

High-impact decisions should not depend on an unreviewed general-purpose model output.

Separate compliance from legal advice

Compliance requirements depend on:

• jurisdiction;
• industry;
• data type;
• workflow purpose;
• affected people;
• level of autonomy; and
• contractual obligations.

Relevant requirements may involve privacy, employment, consumer protection, records, cybersecurity, sector regulation, accessibility, or AI-specific rules.

Governance documentation and technical controls can support compliance.

They do not replace qualified legal, privacy, security, or regulatory advice.

Verify current obligations for the specific workflow before deployment.

Govern AI workflows in Feluda

Feluda is a desktop application for building and running visual AI workflows.

Governance begins in Workbench.

Test the task, model, provider, attachments, and enabled tools using synthetic or approved data.

Review the Activity drawer for tool input, output, and errors.

In Studio, separate AI tasks from deterministic controls.

Use:

• LLM for summarisation, comparison, analysis, and drafting;
• LLM Label for approved categories;
• LLM Extract for named fields;
• Expression for validation, allowlists, thresholds, and routing;
• Emit for selected intermediate evidence; and
• Output for success, review, partial, and error states.

Clear block names and routes make the workflow easier to review.

Use Feluda permissions and Secrets

Feluda flow permissions can allow or deny:

• URLs;
• IP addresses;
• file paths; and
• ports.

Use these controls to enforce the approved network and file boundaries.

Do not broaden access automatically when a tool fails.

Confirm that the destination is part of the approved workflow.

Store API keys and connection values in protected provider or Secrets settings.

Do not place credentials in prompts, files, screenshots, or ordinary workflow text.

Govern Genes, tools, and MCP connections

Feluda Genes can add tools, prompts, flows, and resources.

MCP servers can expose additional tools to Workbench and Studio.

Before enabling one, record:

• source;
• purpose;
• tool list;
• data received;
• read and write capabilities;
• network and file access;
• credential use;
• destination; and
• approval owner.

Enable only the tools required for the use case.

Confirm important actions through activity records and at the destination.

Remove tools that are no longer used.

Use RunFlows and Schedule Manager as governance evidence

Use RunFlows to test saved workflows with normal, exceptional, malicious, and failing inputs.

Review outputs, routes, intermediate Emit values, errors, and tool activity.

Feluda's Schedule Manager supports once, daily, weekdays, weekly, and monthly schedules in paid plans.

It provides upcoming runs, recent history, conflict warnings, and pause or resume controls.

Scheduling runs on the desktop, so Feluda and required local services must be available.

Review scheduled history and pause the workflow before changing models, tools, permissions, destinations, or review requirements.

Use the Feluda Journal carefully

Feluda's Journal can support approved local records such as:

• workflow review notes;
• exception summaries;
• scheduled output;
• change records;
• test observations; and
• monitoring reports.

The Journal Monitor can watch a selected journal.

Do not use the Journal as an uncontrolled store for confidential source material.

Define what may be written, who can access it, and how long entries are retained.

Use identifiers and concise evidence when complete input is unnecessary.

AI automation governance checklist

Before production use, confirm that:

• the workflow is inventoried;
• an owner is named;
• purpose and users are approved;
• risk and autonomy are classified;
• data flow is documented;
• models and providers are approved;
• tools follow least privilege;
• deterministic controls enforce policy;
• review points are meaningful;
• evaluation criteria are met;
• activity evidence is retained appropriately;
• monitoring and alerts are assigned;
• incident and pause procedures are tested;
• material changes require reevaluation; and
• retirement criteria are defined.

Governance should make useful AI automation easier to operate responsibly.

It should not be a one-time form completed before launch.

The strongest governance connects policy to enforceable workflow controls, operational evidence, accountable people, and continuous review.