IT project using artificial intelligence: a practical guide
Managing an AI IT project is no longer a trend. It is an operational necessity for any organisation that wants to compete in 2026. Implementing AI in a technology project is not simply about adding a model to the existing architecture. On the contrary, it requires rethinking planning, data management, quality criteria and governance from the very start. In this guide we analyse how to manage an AI IT project successfully, from conception to production operation.
AI IT project: what makes it different
The project differs from a conventional software project in several fundamental ways. The most relevant is uncertainty. In classic development, the functional requirements are relatively stable. In an AI project, the results depend on data quality, the model’s behaviour and variables that are not always predictable.
Data as raw material
In addition, data is the project’s raw material. Without sufficient, representative, quality data, the model will not work as expected. Because of this, the data analysis and preparation phase usually consumes between 60% and 80% of the project’s total effort. Underestimating this phase is the most frequent and most costly mistake.
An iterative lifecycle
On the other hand, the lifecycle of an AI project is inherently iterative. Unlike waterfall development, the product is not delivered only at the end. Here you work in short cycles of experimentation, training, evaluation and model adjustment. Agile methodology is not an option: it is the only viable approach.
AI IT project: planning and scope
Correctly defining the scope is critical to success. A common mistake is setting overly vague objectives, such as “implement AI in the company”. A good project needs a concrete, measurable use case with demonstrable business impact.
Defining the use case
For this reason, the first step is to identify a real business problem where AI can add quantifiable value. For example: reducing incident-classification time by 40%, automating the generation of status reports or predicting demand with a margin of error below 5%. The more specific the objective, the easier it will be to measure success.
Stakeholders and expectations
Managing stakeholder expectations is especially important in an AI IT project. AI is not magic: it has limitations, requires data and needs time to train and adjust. The Project Manager must communicate one thing from the outset. The first results will be approximate, and the model will improve iteratively.
AI IT project: architecture and tools
Without doubt, architecture decisions determine the project’s long-term success. A well-designed AI IT project clearly separates the data, model, API and presentation layers.
Technology stack
The most common tools include Python as the main language, ML frameworks such as TensorFlow, PyTorch or scikit-learn, MLOps platforms such as MLflow or Kubeflow to manage the model lifecycle, and cloud services such as AWS SageMaker, Azure ML or Google Vertex AI for training and deployment. In addition, containerisation with Docker and orchestration with Kubernetes enable reproducible, scalable deployment.
Integration with existing systems
AI rarely operates in isolation. The model must integrate with the organisation’s existing systems: ERP, CRM, ticketing platforms, BI tools. Integration through RESTful APIs and automated data pipelines is a key part of the architecture. According to Google Cloud, an organisation’s MLOps maturity directly determines the speed and reliability of deployments.
AI IT project: quality and testing
On the other hand, the quality criteria in an AI IT project differ substantially from those of a traditional software project. Here it is not enough to pass unit and integration tests. You have to validate that the model meets specific performance metrics.
Model metrics
The metrics vary by problem type: accuracy, recall, F1-score for classification. MAE, RMSE for regression; latency and throughput for real-time systems. The team must define acceptance thresholds before starting training, not after.
Bias and robustness testing
In addition, a responsible AI IT project includes bias tests to detect discrimination in the model’s outputs and robustness tests to assess its behaviour with out-of-distribution data or manipulation attempts (adversarial attacks). Quality is not just technical performance: it is also fairness and reliability.
AI IT project: governance and compliance
Finally, no AI IT project is complete without a governance framework that ensures regulatory compliance and accountability for automated decisions.
The EU AI Act and documentation
The EU AI Act classifies AI systems by risk level and requires technical documentation, conformity assessments and human oversight for high-risk systems. The regulatory classification must be carried out in the project’s initiation phase, not at the end.
Human oversight and traceability
Every AI IT project must include human-oversight mechanisms for critical decisions, traceability records that allow the model’s behaviour to be audited, and rollback procedures in case of performance degradation. Governance is not bureaucracy: it is the guarantee that the system operates within the defined ethical and legal limits.
In conclusion, managing an AI IT project successfully requires combining technical rigour with business vision, agile methodology with structured governance, and experimentation with risk control. The organisations that master this combination will be the ones leading digital transformation in the coming years.
To complement this: the AI Project Manager role and risk management with GenAI.
Frequently asked questions
For a deeper look at the technical architecture, see the guide to secure enterprise RAG and the analysis of MCP in enterprise projects.
In an IT project with AI the planning cycle changes: estimates carry more uncertainty, you have to iterate with real data, and quality is also measured by the model’s bias and robustness. Classic methodology is not enough; you need to adapt the framework.
Hybrids between Scrum for model development and stage-gate to validate deployment. Pure waterfall does not work; pure agile does not either if there is regulation. You have to combine them. CRISP-DM is still valid for the data-exploration phase; what changes is that you no longer deliver the model and finish: you have to maintain, monitor and retrain it.
Estimate by phases with clear exit criteria: proof of concept, controlled pilot, scoped production and scaling. Each phase has its own budget, and the next one is only approved with verifiable metrics from the previous one.
A PM, a data scientist, a data engineer, someone from security and a representative of the user area. If the user area is missing, you build something technically perfect that nobody uses. In projects subject to the EU AI Act, it is advisable to include someone from compliance or legal from the start: the mandatory documentation piles up from the first line of code.
Contaminated or biased training data, model drift in production, a lack of explainability under audits, and inference costs that scale out of control. All these risks are managed from the planning stage; they are not discovered in production.
A programme to run with little margin for error? See how I have done it.
See the nine case studies