Why AI Projects Need More Than Traditional Software Engineers Alone

In this blog post Why AI Projects Need More Than Traditional Software Engineers Alone we will explain why strong coding skills are necessary for AI projects, but not enough to make them secure, reliable or commercially useful.

Many AI projects start with an impressive demonstration. A developer connects a language model to company documents, asks it a few questions and gets convincing answers. Everyone leaves the meeting believing the difficult work is finished.

Then the real problems appear. The AI gives different answers to similar questions, employees do not trust it, sensitive information is exposed, costs rise unexpectedly or nobody can prove whether the system is saving time. The software may work exactly as designed, yet the project still fails as a business initiative.

AI is not traditional software with a smarter interface

Traditional software follows rules written by developers. If a customer clicks a button, the system performs a predictable action. Engineers can test the expected input and confirm the expected output.

Generative AI works differently. Its core technology is a large language model, which is an AI system trained on large amounts of information to recognise patterns and generate a likely response. It does not retrieve a guaranteed answer from a fixed list of rules.

A business AI system normally includes much more than the model. It may search approved company information, interpret a request, choose a tool, perform an action and ask a person for approval when the risk is higher.

That creates a technology stack with several connected parts:

• The AI model, such as a model from OpenAI or Anthropic Claude, which understands and generates language.
• Business data, such as policies, customer records, product information or documents stored in Microsoft 365.
• Grounding, which means giving the AI relevant, trusted information before it answers.
• Tools and workflows, which allow the AI to create a ticket, update a record or start an approval process.
• Security controls, which decide who can use the system and what information or actions they can access.
• Evaluation and monitoring, which measure whether answers remain useful, safe and accurate after launch.

A traditional software engineer may be able to connect these components. The larger challenge is deciding how they should behave inside a real organisation.

1. Someone must define the business problem

“We need an AI chatbot” is not a useful project goal. It describes a type of technology, not the result the business expects.

A better goal might be reducing the average time required to answer an internal policy question from 20 minutes to three minutes. Another might be helping service staff draft accurate responses without giving the AI permission to send them automatically.

This requires a product owner or business analyst who understands the workflow, the employees involved and the cost of the current problem. Without that role, engineers can build an elegant system that solves the wrong issue.

Before development begins, leaders should be able to answer:

• Which task are we trying to improve?
• How much time or money does that task currently consume?
• What would a successful result look like?
• Which mistakes would be inconvenient, and which would be unacceptable?
• When must a person review the AI’s work?

Clear answers prevent expensive experiments from becoming permanent projects with no measurable return.

2. Domain experts must teach the system what good looks like

Software engineers know how to build systems. They may not know how your finance team approves a supplier, how your legal team assesses a contract or how your service desk identifies an urgent request.

That knowledge usually sits with experienced employees. They understand the exceptions, warning signs and unwritten rules that are missing from process documents.

These domain experts need to help select source information, review test cases and define acceptable answers. Their involvement is particularly important when an AI system influences customers, employees, financial decisions or compliance processes.

This is one reason AI projects cannot simply be handed to the development team with a deadline. The people who perform the work must help design the new way of working.

3. Data specialists determine whether the answers can be trusted

An AI system connected to outdated, duplicated or poorly organised information will produce polished versions of the same confusion. Better prompts cannot repair a broken information base.

A data specialist identifies where trusted information lives, who owns it and how it should be prepared. They may also design the search process that retrieves the most relevant company information for each request.

This is often where Microsoft 365 and Azure environments become more complicated than expected. The information may be spread across SharePoint, Teams, email, databases and line-of-business applications, with different access rules in each location.

Cleaning up that foundation improves more than the AI project. It can reduce duplicated work, make reporting more reliable and help employees find information faster.

4. Security and privacy need specialist attention

An AI assistant can become a new doorway into your company’s information. If access controls are weak, an employee may receive an answer based on documents they were never supposed to see.

AI also creates risks that traditional application testing may not catch. A malicious instruction hidden inside a document could try to manipulate the system. An agent with excessive permissions could take an action that is technically valid but commercially damaging.

Security specialists must apply controls such as identity checks, limited permissions, data protection, activity logging and human approval. Microsoft Defender and Wiz, a cloud security platform that identifies risks across cloud systems, can help teams see weaknesses surrounding the AI workload.

For Australian organisations, privacy must be considered from the beginning. Personal or sensitive information should not be placed into publicly available AI tools without proper assessment and controls. Existing obligations under Australian privacy legislation continue to apply when AI is introduced.

The Essential 8, the Australian Government’s cybersecurity framework designed to reduce common cyber risks, also remains an important security baseline. However, completing an Essential 8 program does not automatically make an AI system safe. AI-specific access, data and output risks still need separate assessment.

5. AI systems need evaluation, not just software testing

Traditional testing asks whether a feature works. AI evaluation asks whether the result is accurate, relevant, safe and useful across many possible situations.

A support assistant might answer ten simple questions correctly but fail when a customer uses unusual wording. A document assistant might summarise a policy well while missing an exception that changes the meaning.

Teams need realistic test sets based on actual business scenarios. They should measure answer quality, incorrect claims, response time, cost and the number of cases requiring human correction.

Testing also continues after launch. Models, source documents and user behaviour change. Monitoring allows the team to detect declining quality before employees quietly abandon the system or rely on a bad answer.

This evaluation discipline complements the controls discussed in managing AI agents safely. Giving an agent rules is important, but leaders also need evidence that those rules work in practice.

6. Adoption and workflow design decide whether value appears

Even a technically strong AI system delivers no return if employees avoid it. People need to understand what it does, what it does not do and when they remain accountable for checking the result.

This requires workflow design, training and change management. Instead of forcing staff to open another application, the AI may need to appear inside Microsoft Teams, Outlook or an existing business system.

A useful AI project fits into the work. It does not expect the work to reorganise itself around the technology.

A practical example

Consider a 180-person professional services company building an AI assistant for client enquiries. Its developers could connect a model to the document library within weeks, but that would only create a convincing demonstration.

Moving into production would require operations leaders to define the enquiry process, subject experts to approve the source material and data specialists to remove outdated documents. Security staff would need to prevent cross-client data exposure, while privacy advisers would assess the use of personal information.

The team would then test hundreds of realistic questions and begin with draft responses requiring employee approval. The first business outcome would not be “we launched AI.” It would be shorter response times, more consistent answers and fewer hours spent searching for information.

This hands-on gap between a demonstration and a working business system is also why organisations are using senior forward deployed engineers. These experienced specialists work directly with business teams rather than building technology in isolation.

What the right AI project team looks like

A mid-sized organisation does not need to hire a large permanent AI department. It does need access to the right capabilities at the right stages.

• A business owner accountable for the outcome.
• Domain experts who understand the real work.
• Software and AI engineers who build the system.
• Data specialists who prepare trusted information.
• Security and privacy specialists who control risk.
• People who can evaluate results and monitor performance.
• A change lead who helps employees adopt the new workflow.

The same principle applies when using AI coding agents to accelerate development. Faster code does not remove the need for sound business decisions, security controls or human review.

Start with the outcome and build the team around it

Traditional software engineers remain essential. But asking them to own business analysis, data quality, AI evaluation, privacy, security and employee adoption is unfair to the engineers and risky for the organisation.

CloudProInc combines more than 20 years of enterprise IT experience with practical expertise across Azure, Microsoft 365, OpenAI, Claude, Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect AI ideas to secure systems and measurable outcomes without the overhead of a giant, faceless provider.

If your AI pilot looks impressive but you are not sure how to make it safe, reliable and valuable, we are happy to take a practical look at what is missing — no strings attached.