How we run an AI program at an airline: policy, accounts, training, visibility, build

Benjamin Thomas · September 8, 2026 · 6 min read

How we run an AI program at an airline: policy, accounts, training, visibility, build

Your staff are already using AI. The useful question is how to put guardrails around it, and this is the program we run at operators to do that. We've rolled it out at five companies so far. It has five parts, and the order matters.

There are real risks with AI. But anyone using frontier models every day can see where this is going: it's going to get good. The companies that build around it now will have a competitive advantage.

1. Write down your AI policy

Before anyone buys a tool, leadership agrees on what AI is used for at this company. Some operators want to automate as much as they can. Others want AI kept to specific tasks, with a person doing every job a customer or regulator sees. Either can work. Having no position doesn't.

The policy is one page in plain language: what AI may do, what it never does on its own, and where a person always signs off. Every later decision about tools, training and projects gets checked against that page.

2. Assume people are already using it, and give them the right accounts

AI today is where Dropbox was when it first came out. Staff started using it long before IT approved anything, because it made their day easier. Banning it didn't work then and won't work now. It just moves the use somewhere you can't see.

So the first practical step is corporate accounts. At Great North we run corporate Claude and corporate ChatGPT accounts. With company accounts you can opt out of your data being used for model training, and you decide what the tools are used for. A personal account on someone's phone gives you neither.

3. Train people

A tool nobody knows how to use safely is a risk, not a control. We run an AI upskilling course for staff, and we've run it for Great North. Training is the cheapest risk control on this list, and it's the one most companies skip.

The course starts with definitions: what the model is, and what the harness around it is. Most confusion about AI comes from mixing those two up. From there it covers the settings that control how a model behaves, like temperature, and how to get controlled, structured outputs instead of free text.

Then it gets practical. People learn how to build an MCP server so the AI can pull numbers from your systems instead of making them up. It works a lot like SQL: the AI asks for the figure, the system returns it, and the number comes from your data, not from the model.

4. Keep visibility

You can't manage what you can't see. Corporate accounts give the company a view of who is using AI and how. That visibility is what turns "we think people are using it responsibly" into something you can actually check.

Hallucination rates keep falling with each new model, but they aren't zero. If your company is very risk averse, insurance for AI errors now exists and is worth looking at. We see it as the last layer, though. It pays out after something goes wrong. The first four steps are there so it doesn't go wrong.

5. Build AI into the work, with a person approving

This is where the return shows up. Chat accounts help individuals. Building AI into a workflow changes how a department runs.

Connect it to your apps through the ForIT MCP

For AI to do real work, it needs access to the systems the work lives in: email, scheduling, HR, finance. The Model Context Protocol (MCP) is the standard way to give an AI assistant that access. Most vendors now ship their own MCP connector, and each one follows that vendor's rules.

We built our own instead. The ForIT MCP is one layer that sits between the AI and all of a company's apps, and it's where the policy from step 1 gets enforced:

  • What it can see. The AI only reaches the systems and data the layer exposes.
  • Permissions by role. A dispatcher's assistant and the finance team's assistant get different access.
  • Confirmation before action. The AI can draft an email, a schedule change or an invoice. A person confirms before anything is sent or changed.
  • An audit trail. Every read and every action is logged, so "who did this and when" already has an answer.

We run ForIT on it every day. For a client, we set up the ForIT MCP in their environment and build it out around their own apps, instead of starting from scratch.

It comes with skills

Access is only half of it. The other half is teaching the AI how your company does a job. We've built skills for the work that comes up again and again, and they come with the MCP.

Presentations are a good example, and the productivity gain on work like this is large. The risk is obvious, though: a polished deck with a wrong number in it looks just as convincing as a right one.

So we built a presentation tool that requires sign-off. A deck the AI produces can't go out until a named person has reviewed and approved it, and that review is recorded. When a deck lands in front of a board or a client, there's a record of who checked it and when.

Then put AI into the workflow

Our clearest example is crew records. Certificates and training records come in, AI reads and cross-checks them, and the chief pilot approves each record with one click. That used to take about 40 hours a month of manual entry. Now it takes 10 to 20 minutes a week of review. Nobody lost a job. The AI never approves anything on its own, and that rule came straight from the policy in step 1.

We've done the same with a minimum equipment list that Transport Canada approved. The AI drafts it, and qualified people review and own the result.

Stay vendor agnostic

We're big advocates of open-source and open-weight models, and of staying AI vendor agnostic. Our bet is that open-weight models will catch up. When they do, a company can buy its own infrastructure and run all of this in its own private cloud. At that point the program is nothing but competitive advantage.

That's also why the ForIT MCP is ours and not a vendor's. The rules, permissions and connections live in our layer, so changing the model underneath doesn't mean rebuilding the program.

The order matters

Most AI projects that go badly skip straight to step 5. Someone builds an impressive demo, there's no written policy, staff are on personal accounts, and there's no training and no visibility. Then the first wrong answer turns into a policy discussion held in the middle of an incident.

Do the first four steps and step 5 gets easier, because every project already has a rule to check against.

If you're working out where AI fits at your operation, we're happy to walk through how we set this up.

Benjamin Thomas

ForIT Team

More from the blog