How I Use AI to Write Procedures: What Works and What Doesn't

Over the past year, I have heard the same question from a number of quality and regulatory professionals: "Do you use AI to write procedures?"

The short answer is yes. The long answer is that it depends very much on how.

I have been working with AI systems for more than two years, and in that time I have developed a fairly clear way of working. That is not because AI is magic, but because I have come to understand where it saves me a significant amount of time, and where it can create problems if it isn't handled correctly.

This article is an honest account of my experience.

Why bring AI into procedure writing at all?

Writing a quality procedure is not a creative act. Most of it is craft: the right structure, coverage of the relevant requirements, clear language and consistency between documents. That is the kind of work where AI can help rather than harm, as long as you understand the rules of the game.

When I compare the procedures I wrote three years ago with the ones I write today, the difference is not in the final quality but in the time it took to get there. A process that used to take three working days (interviewing the client, drafting, editing and closing) can now be finished in a day and a half. That isn't magic. It is a change in the points where I enter the process.

What works well: feeding in context, not asking questions

The most common mistake I see is when people open a conversation with AI and tell it, "Write me a document control procedure according to ISO 13485." What they get back is a completely generic procedure. It is technically correct, but it has no practical value.

What works much better is to provide context before you ask it to write anything. That means who the company is, what the product is, how many people are in the organization, how they manage their document system and which processes already exist. The more context you give, the closer the first output comes to what you need.

For example: a client of mine, a 12-person startup developing a diagnostic device, asked for a change management procedure. Instead of asking AI a generic question, I prepared a short description covering the size of the organization, the development stage, who approves changes and whether there is a formal change board. The procedure I got in the first round needed only 20 minutes of editing, not a rebuild.

What works well: using AI as a "first editor"

One workflow I have fully adopted goes like this. I write the first draft myself, in the first person, based on my understanding of the client. Then I pass it to AI with specific instructions: "Go over this procedure and check that all the relevant clauses of ISO 13485:2016 are covered. Point out any gaps."

This is a smart use of the tool, with AI acting as editor and reviewer rather than author. It is very good at spotting structural gaps, suggesting alternative wording and checking consistency. It is much less good at understanding the business logic behind the procedure.

What works well: creating a skeleton

Another use that serves me in almost every project is a focused request to create only the structure of the document: headings, subsections and the questions each part needs to answer. It saves me from the "blank page" and lets me focus on the real content.

I write the procedure itself. The structure just arrives faster with AI.

What doesn't work: quotations and regulatory requirements

This is where you need to be very careful. AI can quote regulatory requirements inaccurately. That is not because of bad intent, but because language models produce text that sounds plausible even when it is not entirely accurate.

I have seen cases where AI phrased a requirement as "Clause 7.3.3 of ISO 13485 requires...", except that the wording was not accurate. Someone who doesn't know the standard by heart, or who can't be bothered to check the output against the standard, may accept it as fact and put it in the procedure.

My rule: every requirement attributed to a standard, a regulation, an FDA guidance or any other external document is checked against the source. Always, without exception.

What doesn't work: understanding the logic of the organization

AI doesn't know why the QA Manager is also the Management Representative. It doesn't know that this company has no formal change board because it has only three engineers. It doesn't know that this procedure needs to connect to another procedure we wrote six months ago.

All the "human" logic that comes from knowing the client, from meetings and from years of experience is not in the AI. That is why procedures written with AI and without the involvement of a real expert come out technically correct but empty of real content.

Example: I once received a procedure that a client had written with AI before reaching out to me. It was nicely worded and covered the right clauses, but it did not match what the company actually does at all. The approval authority, the review method and who is responsible for what were all "theoretical." We had to rewrite the procedure.

What doesn't work: assuming the AI "understands" the field

AI understands the text of ISO 13485. It doesn't understand an audit. It doesn't understand what an external auditor will look for. It doesn't understand that a certain wording that sounds good on paper will open a difficult question during an audit.

That understanding comes from the expert, not from the tool.

My way of working in practice

To sum up my approach, here is what the process looks like in an average project:

Step 1, understanding the client: an interview, questions, and understanding the organizational structure and the current state of the QMS. This part doesn't change.

Step 2, building context for the AI: before I ask for anything, I write a 10 to 15 line description of the company, the product and the needs. This "context" is what determines the quality of the output.

Step 3, a first structure: I ask the AI for a skeleton of the procedure only, without content.

Step 4, my writing: I fill in the structure based on the knowledge I gathered in step 1.

Step 5, AI review: I pass the draft to the AI with specific questions about requirement coverage, consistency and gaps.

Step 6, editing and approval: every final edit goes through me, and I do a professional review. Every regulatory quotation is checked.

A question people always ask: isn't using AI a problem before an audit?

That's a great question. The simple answer is no, because the procedure represents what the company actually does. It doesn't matter how it was created. What matters is that it is accurate, consistent and implemented.

If your writing process is transparent, based on a real understanding of the organization, and goes through professional editing, there is no problem at all.

The problem arises when a company submits a generic procedure written by AI, without the organization having read it carefully and without it matching reality. In that case AI is not the problem; the writing and adoption process is.

In closing: AI is a tool, not a replacement

AI is the most useful tool to enter my toolbox in recent years.

It saves time, helps with wording and helps me catch gaps. But it does not replace professional judgment, hands-on experience or an understanding of the client.

When it is used well, it multiplies productivity. When it is used badly, it produces a pile of documents that look good but are worth nothing.

What makes the difference between the two? As with any other tool, it is professionals who know what they are doing.