You Can't Predict Who Leads AI in Three Months. Build Accordingly.

Consider where things stood in the middle of 2024. If your association was trying to do something serious with AI, the decision was close to automatic. OpenAI was the undisputed leader. You opened an API account, you built your systems directly around it, and you moved on to the next problem. That was a defensible call. It was arguably the only reasonable one available.

The advantage did not hold. Anthropic's Claude, which existed then but had not yet found its audience, became a serious contender and in some categories a preferred one. Google's Gemini line became genuinely competitive. Reasoning models arrived and changed what these systems could do, since models had previously been taking their best first guess at every question rather than working through a problem and refining an answer.

Any association that hardwired its 2024 assumptions into a system expected to run for five years is now living with a decision that made sense when it was made and does not anymore. The useful lesson has little to do with choosing a better vendor next time. The choosing itself is the wrong place to invest your certainty.

Nobody can forecast this, including the people inside it

It is worth being blunt about the limits here. No one can predict with useful accuracy which company will hold the capability lead at a given moment. That holds true three years out, and it holds true three months out as well.

This is not a knowledge problem you can solve by reading more newsletters, attending more sessions, or hiring the right consultant. The people building these systems cannot tell you where the lead will sit next quarter. The field is moving faster than anyone's forecast can survive.

Which creates an awkward situation for associations specifically, because your planning horizon and the market's rate of change are badly out of sync.

The mismatch with how associations actually build

Associations build systems intended to last considerably longer than a few months. Your AMS decisions run for years. Your integrations outlive the staff who commissioned them, and the person who can explain why a particular field maps the way it does may have left two roles ago.

Look at how the decision actually gets made. A need surfaces, and it competes for attention against everything else the staff is carrying. Someone researches options across several months, usually alongside a full workload rather than instead of one. A recommendation goes to a committee, then to the board, on whatever cycle the board happens to meet. The expenditure lands in a budget that was drafted the previous year. By the time an agreement is signed, a year or more has often passed between identifying the need and switching anything on.

That process exists for good reasons. Associations answer to members and to a board, and spending member money on technology deserves scrutiny. But the process is built to produce durable decisions, and it applies pressure toward long commitments. A three-year agreement is easier to justify than an annual one because it looks like responsible planning and it often costs less per year. Nobody wants to return to the same board in eighteen months to explain why the thing they approved needs replacing.

None of that is a flaw in how associations operate. Long horizons are appropriate for member data, financial systems, and event infrastructure, where the underlying requirements genuinely do not change much. The problem arrives when the same horizon gets applied to a decision about which AI model sits underneath your work, because that particular decision has a much shorter useful life than the process making it assumes.

Consider what that costs in practice. Staff learn the quirks of one system and build workarounds for its weaknesses. Prompts and workflows get written against one model's behavior. Integrations get wired to one provider's specifics. Eighteen months later, a better or cheaper option is available, and the switching cost has quietly grown large enough that the conversation never happens. The commitment was to a vendor, but the accumulated investment sits in everything built on top of it, and that is the part nobody budgets for.

The resolution is not to guess better. It is to build so that guessing wrong costs you very little.

Your choice lives in inference, and it is wider than you think

To act on that, you need to know where your actual decision points are.

Two separate things happen in AI. Training is how a model gets made, which is a long and expensive process of finding patterns across enormous amounts of data. It happens once, and it is somebody else's expense. Inference is what happens when you use the finished model. You submit something, the model produces an answer, and that is inference. It happens every single time, and it is your expense.

Training is a decision you will never make. Inference is a decision you make constantly, and it is where your flexibility lives.

Here is what makes that decision wider than most association leaders realize: the company that builds a model and the company that runs it for you are not necessarily the same company. Think of a model developer as the auto manufacturer, building the vehicle, and an inference provider as the gas station, supplying the fuel to run it day after day. OpenAI, Anthropic, and Google occupy both roles at once. They develop their own models and sell access to run them.

There is also an entire category of companies that only do the second part. They host models on their own hardware and compete on speed, price, reliability, or geography. Many of them run models whose weights have been published openly, meaning any organization with sufficient compute can run those models anywhere, rather than only through the creator's service. The practical effect is that the market you are shopping in contains considerably more than the three or four names that come up in every conference session.

What building for flexibility looks like

• Treat the model as a swappable component. The prompts, logic, and workflows your association develops have durable value. The specific model executing them is a temporary choice. Keep those layers separate enough that changing the second does not mean rebuilding the first.
• Ask vendors what runs underneath. If you are buying an AI-powered product rather than building one, ask which model it uses, whether that can change, and whether you will be notified when it does. A vendor who can move between providers is offering you flexibility whether they describe it that way or not.
• Be cautious with long commitments priced on today's leader. A multi-year agreement built on the assumption that your current provider stays ahead is a bet on something nobody can forecast.
• Match the workload to the model rather than to the brand. A great deal of association work does not require frontier capability. Summarizing, tagging, routine drafting, and classification often run well on cheaper models. Reserving the expensive options for work that genuinely needs them is a straightforward way to stretch a limited budget.
• Retest on a schedule. A comparison you ran a year ago has expired. Rerunning a small evaluation once or twice a year costs very little relative to what it protects you from.

None of this argues for avoiding commitment altogether, which would leave you experimenting indefinitely and shipping nothing. It argues for committing firmly to your own requirements and processes while holding your vendor and model choices more loosely than instinct suggests.

The associations in the strongest position two years from now will not be the ones that picked correctly in 2026. They will be the ones that can change their minds without starting over.