What a CTO should decide in the first 90 days of an AI product

Decide what compounds

A new CTO of an AI product is offered a hundred decisions in the first quarter and can make perhaps ten well. The test for which ten is simple: will this be more expensive to change in a year than it is today? Architecture, evaluation, data, security and IP all pass that test. Most of the rest does not.

I took over technology at DATAmundi in March 2025, a company with two SaaS platforms in production, a research ambition, and clients that are primarily big-tech companies, including frontier labs. What follows is the list I would use again, what I decided first, and what I deliberately left for later.

Weeks one to four: listen and map

Nothing in the decision grid can be decided before the map exists. The first month is for building it.

Clients first: we ran discovery workshops with clients and turned what they told us into a prioritized roadmap, which told me what the product had to become before I had an opinion about how. Then the teams, and finance, and the platforms as they actually ran: where the data lived, what the contracts allowed, what the security posture was, and which parts of the roadmap contained something genuinely new. That last question produced the invention list, which is the first IP decision and costs nothing to make.

Weeks five to eight: the decisions that compound

Five areas, one decision each, in the order I would make them again.

Evaluation before features. Build the judge and the benchmarks first, because every feature shipped afterwards will be measured by them. At DATAmundi that meant an LLM-as-a-judge pipeline validated against human annotation and benchmarks at three levels, public, industrial and production. Architecture. Choose orchestration and retrieval over fine-tuning wherever the product must adapt per client: AIDA Agents needed no fine-tuning, which is why it deploys on a new client’s content in days, and why we were never locked to one model vendor. Data. Decide what you may use, under which contract, and where it may live, before the first model touches it; nothing is harder to retrofit. Security and compliance. Start the boring program in month two, not year two: code and dependency scanning in the delivery pipeline, central logging, a penetration-test plan, the certification calendar, security awareness for everyone, and a policy for AI coding agents that respects confidentiality and the certification’s constraints. IP. Name the inventions, decide what will be filed, and make the rule that nothing is demonstrated before it is filed.

One organizational split, not a reorganization

Research is always crowded out by delivery unless something structural stops it. Make one split and leave the rest of the org chart alone.

Make the technology function two streams with named owners: a delivery stream for urgent features, client deliveries and the platforms in production, and a product stream for the roadmap and the research that connects to research and technology grants, funding and partnership shaping with US and EU universities. Everything else, the evaluation pipeline, the security program, the data rules and the invention list, is shared. The split is small. Its effect, in my case, was that the research got done: ACL 2026 and EAMT 2026 papers and an award-winning product, instead of a roadmap postponed by the next urgent ticket.

Weeks nine to thirteen: ship one loop

By the end of the quarter one product should be running in production with a rater inside it and a benchmark behind it, so that the organization has seen the whole loop once.

For us that loop was AIDA Agents: translator agents, a rater, a post-editor, a benchmark, a CAT-tool integration, real clients. It mattered less that it was translation than that it was complete. A team that has shipped one measured loop knows what the second one costs, and every decision from the grid, evaluation, architecture, data, security, IP, has been exercised once on something real.

What can wait

The discipline is as much about what not to decide.

1. The perfect stack.Frameworks and vendors can be swapped if the boundaries are clean. Decide the boundaries; defer the brands.
2. The full org chart.One split now. Watch the work for a quarter before drawing the rest.
3. The platform rewrite.Modernize the piece the roadmap depends on, with authentication, CI/CD, testing and monitoring, and leave the rest until the roadmap has proved itself.
4. Dashboards before the flows exist.A report on a process that does not yet run is a mock-up. Build the flow, then the report.
5. Vendor consolidation.Cheaper next year than wrong this year.

The receipts

The appointment, and what the decisions produced.