Yvonne Tran spent fifteen years as a cybersecurity architect at a large financial institution before joining a fintech startup as Chief Risk Officer. In 2023 her industry association invited her onto a working group on AI risk assessment frameworks, and she almost declined; she assumed standards work belonged to academics and regulators rather than to people who run systems. She went anyway. Eighteen months later, her practical knowledge of how AI systems actually fail in production had shaped three clauses in a framework now referenced by two national regulators. She walked in believing she had nothing to offer, and turned out to be exactly what was missing.

AI standards development is happening right now, at multiple organizations simultaneously, and it needs practitioners. The people writing the standards are not always the people who will have to live with them, and that gap shows up in the finished text as requirements that read cleanly on the page and buckle on contact with an operational environment. If you have real experience deploying or governing AI systems, your perspective is valuable, and the process for getting it into the right rooms is far more accessible than most professionals realize. This lesson maps the tracks on which AI standards are actually written, explains what practitioners uniquely contribute to them, and shows how to enter the process at whatever level of commitment your job allows.

Who Develops AI Standards and How

There is no single body that writes the rules for AI. Standards emerge from several parallel tracks running at once, each with its own products, timescale, and entry points for outsiders. Knowing which track you are looking at tells you what kind of influence is available and how to reach for it. A voluntary technical framework, a regulator's rulemaking, a trade body's sector guidance, and a government-convened consortium deliverable all shape practice, but they open to contributors in completely different ways, and a contribution aimed at the wrong track simply lands nowhere.

National and international standards bodies develop voluntary technical frameworks. NIST, the US National Institute of Standards and Technology, published its AI Risk Management Framework in 2023; it is the most widely adopted AI governance framework in the US. ISO, the International Organization for Standardization, published ISO/IEC 42001 the same year, the first international standard for AI management systems. Neither document was written behind closed doors. Both were developed through public comment processes and working groups, which means the text you now cite in your own governance documents was shaped by people who chose to respond when the drafts were open.

Regulatory agencies publish guidance, rules, and technical standards through formal rulemaking, and their output binds in a way voluntary frameworks do not. The EU AI Act required the European AI Office to develop supporting standards through the European standards bodies CEN and CENELEC. In the US, financial regulators, healthcare regulators, and the FTC have all issued AI-related guidance that draws heavily on practitioner input submitted through formal comment processes. Rulemaking is procedurally strict and therefore predictable: the comment window opens, it closes, and what arrived inside it is what the agency is obliged to consider.

Industry consortia and professional associations develop sector-specific standards and best practices, often faster than formal regulatory bodies because they are not bound by rulemaking procedure. The Partnership on AI, IEEE, and dozens of sector-specific groups publish frameworks, principles, and technical specifications that shape industry practice even when they are not binding. Their output frequently becomes the raw material that formal bodies later refine, so influencing a consortium document early can matter more than commenting late on the regulation that follows it.

Government-convened working groups such as NIST's AI Safety Institute Consortium bring government, industry, academia, and civil society together in task forces with defined deliverables. This is the track Yvonne joined. Participation is selective and the workload is real, but so is the proximity to the drafting itself.

What Practitioners Uniquely Bring

Standards bodies struggle with a specific and structural problem: the people who have time to participate in long deliberative processes are often not the people with recent firsthand experience of how systems work and fail. Academics understand theory. Lawyers understand compliance. Policy staff understand regulatory intent. Practitioners understand what actually happens when you deploy a model at scale, handle an incident under pressure, or try to explain an algorithmic decision to an auditor who has never seen one before. That knowledge is not written down anywhere a committee can find it, which is why the committee needs a person who carries it.

Workability testing. Does this requirement make sense in an operational environment? A standard that requires real-time human oversight of every AI decision sounds entirely reasonable until you understand that a midsize bank's fraud-detection system makes 400,000 decisions a day. The requirement is not wrong in spirit; it is wrong in mechanism, and only somebody who has watched the traffic go past knows that. Workability feedback is the single contribution practitioners are best placed to make, because it turns an aspiration into a requirement an organization can actually satisfy.

Failure mode documentation. What actually goes wrong, and how? Abstract risk categories in standards often miss the specific failure modes practitioners have seen, because those categories are assembled from literature rather than from incident logs. When you can describe the sequence by which a system degraded, who noticed, what the monitoring missed, and what the eventual fix was, you are giving a drafting committee something it cannot generate on its own.

Implementation feasibility. What does compliance with this requirement actually cost, and what organizational infrastructure does it assume? A standard that assumes a dedicated AI ethics team makes very different demands on a 50-person company than on a 50,000-person company. Requirements written with only large organizations in mind quietly become barriers to entry, and the practitioner who can price the requirement in staff time and tooling is the one who surfaces that effect before it is locked in.

Terminology sanity. Is the language in this framework interpretable by the people who will have to use it? Standards written by technologists for lawyers, or by lawyers for technologists, often produce implementation guidance that satisfies neither audience and generates years of conflicting interpretation. Flagging a term that will be read three different ways by three different functions is unglamorous work with a very long payoff.

Choosing Your Entry Point

The right entry point depends on how much time you have and what you want to contribute. It is better to make one excellent contribution through a low-commitment channel than to join a working group whose cadence you cannot sustain and then go quiet, which costs you credibility with exactly the people you wanted to influence.

Public comment submissions carry the lowest barrier. Most NIST frameworks, proposed regulations, and ISO standards go through public comment periods, and anyone can submit a written response. No membership in any organization is required. A well-structured, concrete, experience-grounded comment from a practitioner, carrying specific examples and clear reasoning, carries weight precisely because so much of what arrives is generic. The US Federal Register lists all open comment periods, and NIST and ISO maintain their own comment portals. If you do nothing else with this lesson, subscribe to the relevant listings so that open windows reach you while they are still open.

Professional association working groups sit at moderate commitment. Most large professional associations in technology, finance, healthcare, and law run AI-focused committees or working groups. Joining one typically requires membership in the association, and commitment is usually two to four hours per month. The work products from these groups often become input to formal standards processes, so the leverage is higher than the hours suggest. This is also where you build the relationships that lead to nominations elsewhere.

Government working groups and consortia are selective. Groups such as NIST's AI Safety Institute Consortium select participants through applications or nomination. The time commitment is substantially higher, typically 8 to 15 hours per month during active deliverable periods, and the influence is correspondingly greater because you are in the room while the language is being settled rather than responding to it afterwards. Go in with your employer's explicit support; participation at this level is not something to run in the margins of a demanding role.

Commenting on other organizations' submissions keeps you in the conversation. Published standards and major comment submissions from industry groups are themselves subject to response. Reading what others have submitted and responding with your own perspective is a genuine form of participation even when you hold no formal seat, and it is the cheapest way to learn how the arguments in a given domain are actually made before you spend your own credibility making one.

How to Make Your Contribution Useful

The most effective practitioner contributions share three qualities, and the difference between a comment that changes text and a comment that is logged and forgotten usually comes down to all three being present at once.

They are specific. "This requirement is too vague" is not useful; it tells the committee nothing it did not already suspect and gives it nothing to act on. Compare that with the following: this requirement says "regular monitoring" without defining frequency or methods, and in our context, a customer-facing chatbot handling 50,000 queries per day, "regular" needs to mean at minimum weekly statistical sampling at a defined confidence level, because anything less leaves material gaps. That version names the defect, supplies the operating context that makes it a defect, and states what would resolve it. It can be turned into draft language by somebody who has never met you.

They are grounded in evidence. Standards committees respond to documentation: incident data, implementation costs, failure rates, organizational case studies. Assertion is cheap in these processes and everybody brings some, so the input that survives contested discussion is the input anchored in evidence from real deployments. You do not need a research programme to do this. Anonymized figures from your own operations, described honestly with their limits stated, are already more than most submissions carry.

They propose alternatives. Critiques without alternatives are noted and set aside, because a committee working to a deadline cannot act on a problem it has no candidate solution for. Critiques paired with workable alternative language are taken seriously. Yvonne's most impactful contribution was not pointing out a problem with a draft clause. It was arriving with replacement language she had drafted with her legal team, ready to discuss, which meant the discussion started from her text rather than from a blank space.

Why Shaping Beats Complying Later

There is a straightforward economic argument for participating, and it is worth making to a sceptical executive who sees standards work as an unpaid hobby. Standards that do not work in practice eventually get replaced by ones that do, but the interval between the two is paid for by every organization that had to implement the first version. Shaping a requirement while it is still a draft costs a few hours of a senior practitioner's attention. Implementing an unworkable requirement, documenting your struggle with it, and then advocating for revision costs years of operational overhead and a great deal more credibility. The same knowledge is deployed either way; only the timing and the price change.

There is a second benefit that is harder to put on a business case. Sitting in a drafting process shows you where the field is going before it arrives, and it shows you the reasoning behind requirements that will otherwise reach you as bare text. Practitioners who have taken part interpret ambiguity more confidently and can explain to their own leadership why a clause says what it says. Yvonne joined a working group to contribute; the return she did not anticipate was a better understanding of the regulatory landscape her firm operates in.

Anti-Patterns

Practitioners who want to contribute usually fail in a small number of recognizable ways, and every one of them is avoidable.

• Assuming you have nothing to offer. This is Yvonne's near-miss and the most common failure of all. Deployment experience is the scarcest input in the room, not the least valuable.
• Waiting to be invited. Public comment periods require no membership, no nomination, and no institutional backing. Treating standards work as invitation-only means missing the track that is genuinely open to everyone.
• Submitting critique without alternative language. A problem statement with no candidate replacement is the easiest thing in the world for a committee to acknowledge and move past.
• Arguing from principle rather than from operations. Everybody in a standards process can argue from principle. Almost nobody else can say what happens at 400,000 decisions a day.
• Aiming at the wrong track. A comment sent to a body with no authority over the clause you object to is effort spent on nothing. Identify who owns the text before you write about it.
• Overcommitting and disappearing. Joining a consortium at 8 to 15 hours per month without securing the time is worse than joining an association committee at two to four hours and showing up reliably.
• Complaining after publication. The window in which text is cheap to change is the drafting window. Objections raised after adoption become implementation problems that you personally have to absorb.

Practice Prompts

Work through these in order; each produces an artifact you can actually use rather than a note to yourself.

• Map your tracks. For your sector, list the specific bodies on each of the four tracks that produce text you already have to comply with or cite. Name the document, not just the organization.
• Find one open window. Locate a currently open comment period relevant to your work through the US Federal Register listings or a standards body's own comment portal, and record its closing date somewhere you will see it.
• Draft a workability comment. Take one requirement from a framework you already implement, describe your operating context in a single concrete sentence including volumes, and state what the requirement would need to say to be satisfiable in that context.
• Attach the evidence. For that same comment, identify what internal data you could cite and what would need to be anonymized or aggregated before it left the building. Clear it with whoever owns disclosure before you need it.
• Write the replacement clause. Turn your critique into proposed language, then have a colleague from a different function read it and tell you how they interpret it. If the two readings differ, the clause is not ready.
• Price your capacity honestly. Decide which entry point matches the hours you can actually protect, and if it is a working group, get your manager's agreement in writing before applying.

Reflection

• Which standards or frameworks does your organization already have to satisfy, and were you or anyone in your function consulted while they were being drafted?
• What is the single requirement you currently implement that you believe is unworkable as written, and what evidence could you produce to demonstrate that?
• Where does your own experience sit among workability, failure modes, implementation cost, and terminology? Which of the four is your strongest contribution?
• What would have to be true about your workload for you to sustain two to four hours a month on an association working group?
• Who in your organization would need to approve the use of internal incident or cost data in a public submission, and have you ever asked them?
• If a clause you object to is adopted unchanged, what will compliance cost your organization over the life of that requirement, and does that exceed the cost of engaging now?

Glossary

• NIST AI Risk Management Framework. A voluntary AI governance framework published in 2023 by the US National Institute of Standards and Technology, and the most widely adopted AI governance framework in the US.
• ISO/IEC 42001. Published in 2023, the first international standard for AI management systems, developed through the International Organization for Standardization.
• EU AI Act. European legislation that required the European AI Office to develop supporting standards through the European standards bodies CEN and CENELEC.
• CEN and CENELEC. The European standards bodies through which supporting standards for the EU AI Act are developed.
• Public comment period. A defined window during which anyone may submit a written response to a draft framework, proposed regulation, or draft standard, without membership in any organization.
• US Federal Register. The publication that lists all open US federal comment periods, and therefore the practical starting point for finding a window that is currently open.
• Working group. A standing or task-specific body that drafts text, with membership by application, nomination, or association membership depending on the track.
• Workability testing. Assessing whether a drafted requirement can actually be satisfied in a real operating environment at real volumes.
• Failure mode. A specific, observed way in which a deployed system goes wrong, as distinct from an abstract risk category.

Related Lessons

Standards participation connects directly to the wider policy work in this program. Standards Development & Participation covers the mechanics of formal participation in more depth, and Policy Advocacy & Government Relations addresses the adjacent skill of engaging agencies outside a drafting process. For the international dimension, Shaping Global AI Governance and Navigating Global AI Regulatory Divergence deal with what happens when the tracks described here produce incompatible requirements in different jurisdictions. Regulatory Landscape & Compliance Requirements is the natural companion if your immediate need is to understand the instruments already binding on you before you attempt to influence the next ones.

Closing

The barrier to contributing to AI standards is lower than almost anyone assumes, and the value of practitioner input is higher than almost any practitioner assumes. The bodies drafting this text are not short of theory, legal analysis, or policy intent. They are short of people who can say what happens when the requirement meets the system, at volume, on a Tuesday. If that is you, the tracks are open: a comment period you can respond to without joining anything, an association committee that asks a couple of hours a month, or a consortium seat if your organization will back the time. Start where your capacity actually is, be specific, bring evidence, and never arrive with a complaint you have not tried to replace with language.

Key Takeaways

• AI standards are developed on four parallel tracks. National and international standards bodies, regulatory agencies, industry consortia and professional associations, and government-convened working groups each produce different text and open to contributors in different ways.
• Practitioners are the missing voice. Firsthand knowledge of workability, failure modes, implementation cost, and terminology is what deliberative bodies struggle most to obtain elsewhere.
• Public comment is the lowest-barrier entry point. Anyone can respond to open NIST, ISO, and regulatory comment periods without membership, and concrete, experience-grounded comments carry disproportionate weight.
• Match the channel to capacity you can defend. Association working groups typically ask two to four hours per month; government consortia typically ask 8 to 15 hours per month during active deliverable periods.
• Effective contributions are specific, evidenced, and propose alternatives. Critique without replacement language rarely changes final text.
• Shaping is cheaper than complying with a bad standard. The interval between an unworkable requirement and its eventual replacement is paid for by the organizations implementing it, including yours.

Frequently Asked Questions

Do I need to be a recognized expert to submit a public comment? No. Public comment periods for NIST frameworks, proposed regulations, and ISO standards are open to anyone and require no membership or credential. What gives a submission weight is that it is specific, grounded in real deployment experience, and offers alternative language rather than objection alone.

How do I find out when something relevant is open for comment? The US Federal Register lists all open federal comment periods, and NIST and ISO maintain their own comment portals. Because windows close on fixed dates, the practical step is to subscribe to the listings relevant to your sector so that a draft reaches you while responding is still possible.

What if my employer will not let me cite internal data? Ask early rather than at the deadline, and propose anonymized or aggregated figures instead of raw operational data. A described pattern, stated honestly with its limits, is still more useful than an assertion with nothing behind it.

Is a professional association working group worth the membership cost? It depends on whether you can protect the two to four hours a month the commitment typically requires. The work products of these groups often feed into formal standards processes, so the influence is greater than the hours suggest, but a seat you cannot attend reliably costs you credibility rather than building it.

How do I persuade my leadership that this is worth my time? Frame it as cost avoidance. Shaping a requirement while it is a draft costs a few hours; implementing an unworkable requirement and then advocating for its revision costs years of operational overhead. Add the intelligence benefit: participants understand incoming requirements earlier and interpret them more confidently than those reading the published text cold.