AI Governance for Startups: Intake, Risk Register and Sign-off

Nobody can say which AI features exist, what data they read, or who approved them. That stays invisible until a customer is hurt or a partner asks for a list, and then the answer takes weeks.

Picture a common setup. A home-loan marketplace of about 45 people collects buyers' documents once and matches them with partner banks and housing finance companies. The setup is made up, but the problem is real.

The engineering team has five AI features in the pipeline, and two are already live. Nobody wrote down what each one does, what data it reads, or who said yes.

• A listing writer that drafts property descriptions from a builder's floor plans and photos.
• A support chatbot that answers questions about EMIs (equated monthly instalments, the fixed monthly loan payment) and missing documents.
• A document reader that pulls salary, employer and bank balance from uploaded salary slips and statements.
• An eligibility pre-score that ranks each applicant and decides which partner lenders see the file first.
• A coding assistant that helps the engineers write and review code.

Then two things happen in one month. The chatbot tells a buyer the interest rate is 8.1 percent when the lender's real rate is 8.9 percent. The buyer posts a screenshot, and it spreads.

A week later, the risk team at the biggest partner bank sends an email. They want every AI system that touches their applicants, who approved each one, and how it is tested. The founder cannot answer by Friday.

The founder asks the risk lead to fix this, with one condition: do not turn the company into a bank. The rest of this guide follows what the risk lead builds, and why it barely slows the engineers down.

An AI governance framework is the agreed way a company decides which AI features to build, how risky each one is, what checks it needs, and who answers for it. It covers the whole life of a feature, from idea to switch-off.

Think of how many Indian families handle money at home. Nobody asks permission to buy milk. A new mixer-grinder gets a quick word with one elder. A scooter on EMI waits for a family huddle after dinner, where everyone hears the price and the risks.

Map it part by part. The milk is a low-risk internal tool, the quick word is a single reviewer, and the huddle is a founder-level sign-off for a feature that touches loans. The family's notebook of big purchases is the risk register.

Where the picture breaks: a family can quietly absorb a bad purchase. A wrong loan score hurts a stranger who never sat in the huddle, and a partner or regulator may ask for records a family never keeps.

The plan needs four words. Each gets a plain meaning and an example from the marketplace.

Intake. Intake is the first step, where someone describes a new AI feature on a short form before building far. Example: an engineer answers eight questions about the document reader.

Risk tier. A risk tier is a level, such as 1, 2 or 3, that sets how much checking a feature needs. Example: the coding assistant is tier 1, and the eligibility pre-score is tier 3.

Risk register. A risk register is one shared list of every AI feature, with its owner, tier, known risks, checks and review date. Example: one row says the chatbot can quote a wrong rate, and names the fix.

Sign-off. A sign-off is a named person's recorded yes, given before a feature launches or changes. Example: the risk lead and the founder both sign before the pre-score ranks real applicants.

The risk lead also borrows from a published framework. NIST, the US National Institute of Standards and Technology, released its AI Risk Management Framework (AI RMF 1.0) on 26 January 2023, for voluntary use.

It groups the work into four functions: Govern, Map, Measure and Manage. Govern is the part this guide is about: policies, accountability and roles. The framework says its actions "do not constitute a checklist" and does not prescribe how much risk to accept. That is permission to start small.

An AI intake form should ask what the feature does, whose data it uses, who sees its output, what decision it affects, and what happens when it is wrong. Eight short questions are enough to pick a tier.

The naive first try is a 40-question form. Engineers skip it and ship anyway, so the register misses the very features it was meant to catch. The second draft fits on one screen and takes about ten minutes.

• What does the feature do, in one sentence a customer would understand?
• Who is the owner, the one person who answers for it after launch?
• Does it read personal data, such as PAN (Permanent Account Number, India's tax ID), salary, bank statements or phone numbers?
• Does any output reach a customer without a person checking it first?
• Does it affect credit, pricing or who gets a loan?
• Does it send data to an outside service, and where is that service hosted?
• What is the worst realistic mistake, and who gets hurt by it?
• How will you switch it off quickly if something goes wrong?

The last question matters more than it looks. A feature with a kill switch (a setting that turns it off without a new release) is far safer to try. NIST's framework asks for processes to decommission and phase out AI systems safely (its item GOVERN 1.7).

Here is the document reader's intake in short. It reads salary slips, which are personal data. Its output reaches lenders only after an operations person confirms the numbers, and it does not decide credit. That puts it in tier 2.

You sort AI features into tiers by asking a few yes or no questions about impact, starting with the most serious. The first yes decides the tier, so sorting takes minutes and two people usually get the same answer.

The marketplace uses three tiers. Tier 3 is any feature that affects credit, pricing or who gets a loan. Tier 2 is any feature that reads personal data or talks to customers without a person checking first. Everything else is tier 1.

The strictest tier follows a pattern you also see in law. The EU AI Act lists AI systems that judge a person's creditworthiness or set their credit score as high-risk. They sit in point 5(b) of Annex III, the Act's list of high-risk uses. Systems used to detect financial fraud are excluded from that item.

India's central bank, the RBI (Reserve Bank of India), drew a similar line. Its 2025 FREE-AI report (Framework for Responsible and Ethical Enablement of AI) gives document summarisation and email classification as low-risk examples. Credit underwriting, deciding whether to lend and on what terms, is one of its high-risk examples.

The marketplace serves buyers in India, so the EU law is not its rulebook. Both sources still point the same way: lending decisions get the most care.

Follow the questions from top to bottom in the diagram. Notice that a feature stops at the first yes, so the strictest question is always asked first.

Because the rules are simple, the engineering manager puts them in code. The intake form saves its answers as a small dictionary, and this function returns the tier.

HIGH_IMPACT = {"credit", "pricing", "eligibility"}

def pick_tier(intake):
    if intake["decision_area"] in HIGH_IMPACT:
        return 3                     # can change who gets a loan
    if intake["uses_personal_data"] or intake["unchecked_to_customer"]:
        return 2
    return 1                         # internal, no personal data

reader = {"feature": "document-reader", "decision_area": "documents",
          "uses_personal_data": True, "unchecked_to_customer": False}
prescore = {"feature": "eligibility-prescore", "decision_area": "eligibility",
            "uses_personal_data": True, "unchecked_to_customer": False}
print(pick_tier(reader), pick_tier(prescore))   # prints 2 3

What just happened? The document reader got tier 2, and the pre-score got tier 3 even though it also reads personal data. The credit question runs first, so the feature in the puzzle above lands in tier 3, not tier 2.

Tier 1 is what is left when every risky answer is no. A decision area typed differently, such as "Credit" with a capital C, skips the tier 3 check and can land in tier 1. So the intake form should offer a fixed list of areas, not a free text box. Run the file with python3 and you should see the two numbers 2 and 3 on one line.

Here is how the five features land. The review gaps are the risk lead's own targets, not rules from any law. A bias test checks whether results are unfair to one group of applicants.

An AI risk register is one shared, living list of every AI feature in the company. Each row has an owner, a tier, main risks, checks and a next review date. It answers "what AI do we run?" in one place.

Back to the household notebook: it records what was bought, when, the warranty date and who looks after it. Nobody writes down the milk. The register differs in one way: every AI feature gets a line, even tier 1.

Recording tier 1 features is the key difference from a heavy process. A row takes about five minutes. It means the founder can always say how many AI features exist, which is exactly what the partner bank asked.

Published guidance asks for the same list. NIST's framework says mechanisms should be in place to inventory AI systems, resourced by risk (GOVERN 1.6). RBI's 2026 model risk guidance, still a draft on 19 October 2026, is aimed at regulated entities, meaning the banks and other lenders RBI supervises. It says no model should be used unless it is in an inventory.

The marketplace is not a bank, but its partners are regulated. When a lender acts on that advice, expect it to ask its suppliers similar questions. A ready register turns that email into a short job.

Each row holds nine fields. Most take one line to fill in.

• Feature name and a one-line purpose a customer would understand.
• Owner: one named person, never a team.
• Tier, with the intake answers that set it.
• Data used, and any outside service the data is sent to.
• Top three risks, each written as a concrete bad day.
• Checks for each risk, such as a test, a human review or a limit in code.
• Who signed, on what date, and for which version.
• Status: idea, testing, live, paused or retired.
• Next review date, set from the tier.

Here is the chatbot's row after the wrong-rate incident. Its top risk is quoting a rate that is not the lender's current rate. The check: rates now come only from the lender data feed, and the bot shows the date of that rate.

Sign-off depends on the tier: the owner alone for tier 1, the risk lead for tier 2, and the founder plus the risk lead for tier 3. Every sign-off records a person, a date and a version.

This is the family huddle in practice. A bad pre-score could cost a lender partnership, so the founder must be in the room.

Executive responsibility is not just the risk lead's idea. NIST's framework says executive leadership should take responsibility for decisions about AI risks (GOVERN 2.3). The RBI committee report recommends a board-approved AI policy for regulated entities.

At a 45-person startup, the board-level version is simple. The founder signs a two-page AI policy once. It names the tiers, the sign-off rules and the risk lead as the person who keeps the register.

Here is the tier 3 path for the eligibility pre-score. Start at the owner's request and follow the arrows. Notice that a failed check goes back to the owner with a reason, not straight to a no.

The first time through, the pre-score failed its bias check. Applicants with self-employed income were ranked lower, even when their bank balances were strong. Testing for unfair results like this is its own skill, covered in the SevyDevy guide on AI bias testing.

The team removed one input that mostly stood in for job type, then tested again, and the second run passed. In the limited launch, operations staff overrode about 6 percent of scores (made up), which became a number to watch.

1. 1

   Owner prepares the packet

   The owner attaches the register row, test results on 2,000 past files, the kill switch setting and the human review plan.

2. 2

   Risk lead reads it first

   The risk lead reads the packet two days before the meeting and writes questions into the register row.

3. 3

   Short decision meeting

   The founder, the risk lead and the owner meet for 30 minutes. They decide yes, yes with conditions, or not yet.

4. 4

   Record the decision

   The risk lead records who signed, the date, the model version and any conditions, such as the 10 percent limit.

5. 5

   Set the next review

   The register sets a review 90 days out. Any change to inputs or the model version reopens sign-off.

You put governance into the pipeline with two small scripts. One lists overdue reviews every week, and one blocks a deploy when an AI feature has no register row or lacks a required sign-off.

A weekly reminder for overdue reviews

A register is only useful if it stays current, and nobody wants to chase owners by hand. This script runs every Monday and lists every live row whose review date has passed.

from datetime import date, timedelta

REVIEW_DAYS = {1: 365, 2: 180, 3: 90}   # gap between reviews, per tier

def overdue(register, today):
    late = []
    for row in register:
        due = row["last_review"] + timedelta(days=REVIEW_DAYS[row["tier"]])
        if row["status"] == "live" and due < today:
            late.append((row["feature"], row["owner"], due))
    return late

register = [
    {"feature": "eligibility-prescore", "tier": 3, "owner": "eng-manager",
     "status": "live", "last_review": date(2026, 6, 1)},
    {"feature": "support-chatbot", "tier": 2, "owner": "support-lead",
     "status": "live", "last_review": date(2026, 9, 2)},
]
for feature, owner, due in overdue(register, date(2026, 10, 19)):
    print(f"{feature}: review was due {due}, ask {owner}")

Run it and you should see one line: "eligibility-prescore: review was due 2026-08-30, ask eng-manager". The pre-score was last reviewed on 1 June 2026, and 90 days later is 30 August 2026.

The chatbot does not appear. Its 180-day gap runs from 2 September 2026 to 1 March 2027. The REVIEW_DAYS line is the policy written as data. Only live rows are checked, so paused, retired and not-yet-live features stay off the list.

A release gate that blocks unregistered AI features

The second script runs in the deploy job. It refuses any AI feature with no register row, and any tier 2 or tier 3 feature without a recorded sign-off.

def check_release(feature, register):
    row = next((r for r in register if r["feature"] == feature), None)
    if row is None:
        return False, "no register row"
    if row["tier"] >= 2 and not row["signed_by"]:
        return False, "tier 2 or 3 needs a recorded sign-off"
    return True, "ok"

register = [
    {"feature": "support-chatbot", "tier": 2, "signed_by": "risk lead, 2026-09-02, v4"},
    {"feature": "eligibility-prescore", "tier": 3, "signed_by": None},
]
for name in ["support-chatbot", "eligibility-prescore", "listing-writer"]:
    ok, why = check_release(name, register)
    print(name, "->", "deploy" if ok else "blocked: " + why)

Expected output, three lines: the chatbot deploys, the pre-score is blocked for a missing sign-off, and the listing writer is blocked because it has no row. In a real pipeline, exit with a non-zero code when blocked, so the deploy job stops. This gate checks only that a sign-off exists, not who gave it or for which version. A fuller gate compares the signed version with the one being deployed and, for tier 3, needs both names.

How does the gate know which deploys are AI features? It does not, on its own. One simple answer is a flag in each service's config that marks it as an AI feature, which the gate reads before deploying.

You keep AI governance fast by making the low-risk path almost free, setting time limits on reviews, and putting checks into tools engineers already use. Slow governance usually comes from treating every feature like the riskiest one.

If the family called a huddle for milk, people would stop asking and just buy things. Engineers behave the same way, and then the register misses exactly the features that matter.

The risk lead measures the process like a product. After two months, tier 1 features go live the same day. Tier 2 reviews take two working days on average, and the one tier 3 sign-off took nine days (all made up).

• Self-serve tier 1. The owner fills in intake and adds a row, with no meeting and no waiting.
• Review deadlines. A tier 2 review that takes over three working days goes to the founder, so delays become visible.
• Reusable checks. Once the chatbot's rate check exists, the next customer-facing feature can copy it.
• Checks in the pipeline. The release gate refuses to deploy an AI feature with no register row.
• Limited launches. A tier 3 feature can start at 10 percent of traffic with a kill switch, instead of waiting for perfection.
• Change triggers, not calendars alone. A new data source or model version reopens review; a typo fix does not.

The RBI committee report argues for the same balance. To foster innovation, its executive summary recommends "a more tolerant approach to compliance for low-risk AI solutions".

The diagram shows how the pieces connect once the system runs. Follow the arrows from the intake form, and notice that no flagged AI feature reaches production without passing the release gate.

The incident log closes the loop. When the chatbot misquoted the rate, the fix went into the chatbot and the risk went into the register. Handling AI incidents step by step has its own SevyDevy guide on AI incident response.

Follow the laws that apply to your data and customers first, then your partners' contracts, then a voluntary framework for structure. For an Indian lending startup, partner lenders' questions often arrive before any AI-specific rule does.

You do not need to adopt a whole framework on day one. Borrow its vocabulary and its most useful ideas, and grow from there.

• NIST AI Risk Management Framework: the four functions, an AI inventory, executive responsibility and safe decommissioning. It is voluntary.
• NIST's Generative AI Profile (NIST AI 600-1, 26 July 2024): a companion covering risks specific to generative AI, the kind that writes text or makes images.
• RBI FREE-AI committee report (13 August 2025): seven principles called Sutras and 26 recommendations under six pillars, including a board-approved AI policy.
• EU AI Act: a clear example of tiering by use, with credit scoring of people listed as high-risk.
• India's Digital Personal Data Protection Act, 2023: personal data may be processed only for a lawful purpose, usually with consent after a clear notice. The document reader's salary slips count.

Each line in that callout has detail worth knowing. The EU change came in the Digital Omnibus on AI, a package of amendments that simplifies the AI Act. It is Regulation (EU) 2026/1744 of 8 July 2026, and it moved the Annex III date from 2 August 2026.

RBI's website carries a draft "Guidance on Regulatory Principles for Model Risk Management, 2026", which covers AI and machine learning models. Besides the inventory rule, it says each model's risk tier should be reviewed at least annually.

India notified the Digital Personal Data Protection Rules on 14 November 2025, with an eighteen-month period for phased compliance. Check the current text before relying on any of these dates.

A word of caution on RBI. The FREE-AI report is a set of recommendations, and the model risk guidance is a draft aimed at regulated entities. Neither places duties on a supplier like the marketplace directly. Ask your partners what they now require before promising anything.

Laws on data location and privacy also shape the intake form's sixth question, about outside services. Say the document reader sends salary slips to a model service abroad. That answer gives its tier 2 review a first question: where does the data go, and on what terms?

Explain AI governance as a control layer around the system: intake decides the tier, the tier decides the checks, and a register plus monitoring keeps it honest after launch. Then show it stays fast for low-risk features.

1. 1

   Ask what the AI decides

   Find out whether the feature affects money, credit, health or access. That one answer sets most of the design.

2. 2

   Propose tiers

   Give two or three tiers with a simple rule for each, and say the first yes decides.

3. 3

   Draw the register

   Show one table of AI features with owner, tier, risks, checks and review date, and a release gate that reads it.

4. 4

   Add human oversight where it counts

   For the top tier, add human review of decisions, an override with a reason, and a kill switch.

5. 5

   Close the loop

   Log incidents and overrides, review them on a schedule, and reopen sign-off when the model or data changes.

6. 6

   Defend the speed

   Say how long each tier takes to launch, and how you stop low-risk work from waiting in a queue.