Raft’s AI КОМП-АС framework: how to avoid mistakes when choosing the architecture of an AI solution

Most corporate AI initiatives fail before the first line of code is written. Not due to technological limitations or lack of data — but due to an incorrectly chosen direction from the very start. This is the systemic problem that section "A" of the AI COMP-AS framework, developed by the Raft team, solves: a methodology for architectural and product design of AI services that allows you to determine the right direction and calculate return on investment before development begins.

AI COMP-AS is a methodological framework for assessing and designing custom AI solutions in a corporate environment. The abbreviation reveals its structure: Architectural-product design, Components cost, Modularity, Performance, Architecture of data, Scenarios of application. Each block is a separate methodology with specific questions and decision-making criteria.

The framework is aimed at teams planning to build custom AI products from scratch or based on open-source models, rather than implementing ready-made SaaS tools. For such teams, the cost of an architectural error discovered at a late stage can exceed the entire initial budget. Section "A" describes the phase that precedes any technical development.

It is a set of tools for answering four key questions that most teams either ignore or solve intuitively — and this is exactly where future problems are laid down. The first question is problem statement. Most AI initiatives start with vague formulations: "we want a smart chatbot," "we need document processing automation."

The framework proposes a structured path: from business goal — to functional requirements — to a specific AI task with measurable success criteria. This step often reveals a gap between what business wants and what is technically feasible in reasonable timeframes. The second question is choosing the type of solution.

Not every task requires custom development. COMP-AS offers a matrix: when it is sufficient to integrate a third-party provider's API, when you need fine-tuning an existing model on corporate data, and when development of architecture from scratch is justified. This choice directly determines budget, timeline, infrastructure requirements, and future support costs.

The third question is ROI assessment before development begins. One of the central principles of COMP-AS is controlled return on investment. The authors show how, at the design stage, to form a basic economic model: define key performance metrics, calculate break-even points, and model failure scenarios.

This gives teams a tool for timely project shutdown — before resources have already been spent. The fourth question is high-level architectural decisions. The choice between a RAG system and fine-tuning, between cloud and on-premise, between centralized and distributed architecture — all this is determined at the start.

Architectural decisions made in the early phase set constraints for all subsequent development. Reworking fundamental decisions at later stages costs multiples more than making the right choice at the beginning. According to industry analysts' estimates, most corporate AI pilots never reach production.

The main reason — not technological limitations, but the absence of a structured design approach. For companies where multiple teams are conducting AI initiatives in parallel, the lack of a common methodology leads to incompatible architectural decisions and duplication of effort. Frameworks like AI COMP-AS fill precisely this gap — they give teams a common language and clear criteria for decision-making.

The Raft team's series of materials will continue with breakdowns of the remaining sections: component costs, modularity, performance, data architecture, and application scenarios. For practitioners currently evaluating AI initiatives or preparing to defend budgets before management, section "A" is a useful entry point: it poses the right questions before architectural decisions become irreversible.