Major shortages of qualified professionals for key IT roles will lead to huge competitive challenges for organizations that fail to prioritize tech recruiting over the next couple of years, industry observers say.

Hiring the right staff has always been a prime concern for IT leaders, but the pressure to find the right candidates has never been higher, with qualified AI, cybersecurity, and data science professionals especially difficult to find.

Worse, those three domains, along with business/IT automation and risk management, make up the top five areas where CIOs are hiring today, according to CIO.com’s State of the CIO survey. Everyone appears to be hunting the same scarce resources — a market condition that’s already undercutting enterprise opportunities, around AI in particular.

As a result, IT hiring practices over the next 18 months to two years could make or break companies, with laggards risking a huge competitive disadvantage, experts suggest.

Organizations need to think both about hiring outside workers and retraining existing employees to cover gaps, says Adam Wachtel, CTO at employee onboarding platform provider Click Boarding. IT leaders should think wholistically about building capabilities in their teams, he suggests.

“The market for pure AI specialists is volatile and expensive and keeps shifting,” he notes. “What separates organizations right now is whether they’re building AI capability into the team they already have or waiting to buy it fully formed from outside; those building make progress while those waiting are falling behind, and it’s only becoming more expensive.”

There are major implications for organizations that fall behind, Wachtel adds.

“The most immediate risk is technical debt you can’t see accumulating until it’s expensive to fix,” he says. “I’ve lived through rebuilding a team and a platform from a thin, overstretched state, and the lesson that stuck with me is that understaffing or misaligned hiring fails quietly through slower development, more fragile systems, engineer burnout, and more time fixing versus building — it’s not fun for anyone.”

There are several implications for botched hiring efforts, notes Henry Vassal Jones, CIO at outsourcing provider Emapta.

“If you don’t have the people and capabilities to execute, transformation slows, product releases get pushed out, and existing teams carry more of the burden,” he says.

Risk of failure

Critical AI initiatives can fail without the right people in place, Jones notes. “Companies can invest heavily in AI platforms, but without people who understand the business processes, data, governance, and security behind those tools, much of that investment will never reach its potential,” he says.

Jones agrees that employee training, as well as strategic hiring practices, plays an important role in keeping organizations reaching their capacities.

Successful companies will broaden their approaches beyond constrained local or regional talent markets and develop their existing people, he says.

“Those that don’t risk seeing the gap between what the business needs and what their technology teams can deliver continue to widen,” Jones adds. “For CIOs and CTOs, this is no longer simply about filling open positions; it’s about building a talent model that gives the organization access to the right capabilities when needed.”

How to approach the talent challenge

When it comes to developing that talent model, Konstantinos Dolkas, CTO of cybersecurity upskilling and workforce development company Hack The Box, calls for IT leaders to broaden their geographic horizons. While talent is distributed, most hiring strategies still aren’t, he says.

He also advocates employee upskilling. “Recruiting externally can’t be the entire solution,” he says. “Build the majority, buy the scarcity. That could mean a few genuinely senior external hires to set patterns and mentor.”

Given shortages in AI and cybersecurity skills, hiring leaders should also focus more on demonstrated skills from outside hires than the titles they’ve held, Dolkas suggests.

“The best strategy is to hire for demonstrated ability, not credentials,” he says. “Put candidates in a hands-on environment and watch them work. It’s the only screen that survives contact with reality.”

Assessing AI security skills can be particularly difficult in a field that reinvents itself every quarter, Dolkas adds. Another challenge is separating genuine AI fluency from tool familiarity: “Prompting an assistant is not the same as securing an agentic system,” he says.

Anticipate the market and focus on future needs

In addition to building from within, smart IT leaders are focusing on the capabilities their organizations need one to three years from now, says Tom Ioele, CEO at recruiting firm TalentBridge.

IT leaders involved with hiring decisions should think about building talent communities before the demand exists, he says. Organizations should continuously identify and engage with people who have the skills they know they will need, instead of starting to search when a requisition opens, he advises.

“The biggest mistake companies make is treating hard-to-find technology talent like a traditional requisition,” Ioele says. “By the time an AI engineer, cybersecurity expert, or data scientist hits the open market, every company is competing for the same person.”

The companies that win won’t necessarily have the largest recruiting teams, but they will have the best talent intelligence and the ability to activate it faster than their competitors, he adds. Successful organizations will build talent capacity before they need it, he says.

“We’re entering a market where the skills companies need are changing faster than traditional workforce planning cycles,” Ioele says. “Organizations that continue operating through a simple post-a-job, screen resumes, fill-a-seat model will constantly be reacting to yesterday’s demand.”

See also:

• CIOs get serious about closing the skills gap — mainly from within
• 9 tips for recruiting high-end IT talent
• 15 mistakes that make hiring IT talent harder
• 9 upskilling tips that pay dividends

Organizations continue to invest heavily in the cloud, with IT leaders reporting that 26% of their IT budget will be allocated to cloud computing within the next year, according to the 2026 Foundry Cloud Computing Study.

The survey also found that 74% of IT leaders have accelerated cloud migrations in the past 12 months compared to 70% in 2025 and 63% in 2024. Three in four (73%) also said cloud capabilities have helped their organizations achieve “increased and sustainable revenue over the past 12 months.” Overwhelmingly, 80% of respondents from North America and APAC noted that their cloud strategies have helped accelerate the adoption of AI, while that number drops to 68% for the EMEA region.

This growth in cloud adoption, along with accelerated interest in AI, has sparked an increased demand for certain cloud roles. Here are the roles companies are most likely to have added to support their cloud investments, according to Foundry’s research.

And for those looking to break into this lucrative IT pathway, see “Where to begin a cloud career” and “18 best entry-level IT certifications to launch your career,” which includes several good cloud-related credentials to get started with.

AI/ML engineer

The role of AI/ML engineer is in high demand as organization expand their AI strategies. These professionals design and implement AI and machine learning systems, overseeing them in operation to identify opportunities for improvement, ways to better automate processes, and how to better inform decision-making across the organization.

Skills: Skills for this role include programming, knowledge of machine learning, data science, data engineering, and experience building AI systems using APIs. See also: “The hidden skills behind the AI engineer.”

Role growth: 36% of companies have added AI/machine learning engineers as part of their cloud investments, according to Foundry’s survey.

AI platform engineer

An AI platform engineer is responsible for building and running the internal systems that businesses use to build and scale AI tools and initiatives. As organizations increasingly adopt AI internally, they’re hiring professionals to help navigate the daily operations of internal developer platforms (IDPs) that use AI to boost productivity and drive automation.

Skills: Skills for this role include understanding of cloud infrastructure, programming languages, and orchestration and container technology, including Kubernetes and Docker.

Role growth: 27% of companies have added AI platform engineers as part of their cloud investments.

Cloud architect

As cloud computing grows increasingly complex, cloud architects have become vital for navigating the nuances of implementing and maintaining cloud environments. These IT pros can help organizations avoid cloud security risks, while also ensuring a smooth transition to the cloud. With 65% of IT leaders choosing cloud-based services by default when upgrading technology, cloud architects will only become more important for enterprise success. For those interested in this role, see “IT career roadmap: Cloud architect.”

Skills: Skills for this role include knowledge of application architecture, automation, ITSM, governance, security, and leadership.

Role growth: 21% of companies have added cloud architect roles as part of their cloud investments.

Cloud software engineer

Cloud software engineers are tasked with developing and maintaining software applications that run on cloud platforms, ensuring they are built to be scalable, reliable, and agile. Companies that have migrated to the cloud often need IT pros who can build company-specific services and applications to make the most of the cloud environment. For more on this career path, see “IT career roadmap: Cloud engineer.”

Skills: Relevant skills for a cloud software engineer include Python, Java, C#, JavaScript, microservices architecture, serverless computing, APIs and SKDs, DevOps, cybersecurity, and knowledge of the agile methodology.

Role growth: 20% of companies have added cloud software engineer roles as part of their cloud investments.

Cloud developer

Cloud developer is a vital role for developing and deploying software in cloud environments. These IT pros are tasked with designing, creating, and deploying applications designed to run on cloud platforms, with a focus on building scalable, reliable, and cost-effective solutions to meet business needs.

Skills: Relevant skills for a cloud developer include programming languages such as Java, C#, and Python as well as knowledge of popular cloud platforms, microservices architecture, database storage, agile methodology, APIs and SKDs, and containers and orchestration.

Role growth: 20% of companies have added cloud developer roles as part of their cloud investments.

Security engineer

Security engineers are tasked with overseeing the security of an organization’s systems, networks, and data, to make sure they’re protected from cybersecurity threats. For organizations investing in the cloud, security engineers can help ensure services, applications, and data running on cloud platforms are secure and compliant with any government regulations.

Skills: Network security, IAM, encryption, vulnerability management, security architecture, cloud security, automation, and infrastructure design and optimization.

Role growth: 19% of companies have added security engineer roles as part of their cloud investments.

Cloud consultant

With the rapid adoption and move to the cloud, organizations look for professionals who can leverage cloud technologies to meet business needs, grow the business, and improve efficiency. Cloud consultants are cloud experts who stay on top of the latest innovations in cloud technology to better advise business leaders.

Skills: Knowledge of architecture and solution design, DevOps, automation, project management, cloud security, compliance, cloud migration, and knowledge of popular cloud platforms.

Role growth: 16% of companies have added cloud consultants as part of their cloud investments.

Security architect

Security architects are responsible for building, designing, and implementing security solutions in the organization to keep IT infrastructure secure. For security architects working in a cloud environment, the focus is on designing and implementing security solutions that protect cloud-based infrastructure, data, and applications.

Skills: Security architecture design, network security, security compliance and governance, incident response and forensics, data encryption, IAM, automation, and DevSecOps.

Role growth: 16% of businesses have added security architect roles as part of their cloud investments.

Cloud product manager

With cloud adoption often comes an increase in in-house development of cloud-based services. A cloud product manager can help cloud teams develop effective solutions aimed at fulfilling business objectives. They’re also tasked with using their deep understanding of product management within the cloud environment to work closely with key stakeholders, identify and define requirements from users or customers, develop product roadmaps, and oversee the QA process to gain feedback on how to improve product offerings. 

Skills: Product management, UX design, communication and collaboration, and a strong technical background.

Role growth: 16% of organizations have added cloud product manager roles as part of their cloud investments.

Cloud governance/compliance manager

Cloud governance and compliance managers help companies navigate the complexities of security, governance, international regulation, and internal policies. They identify potential risks, implement automated tools to oversee security and compliance, and help businesses maintain secure cloud operations.

Skills: A strong knowledge of regulatory policies such as GDPR, HIPAA, PCI DSS, and other international data protection laws. Additional skills include knowledge of tools such as CSPM, Azure, AWS, Microsoft Purview Compliance Manager, and other IT governance tools.

Role growth: 16% of businesses have added cloud governance and compliance manager roles as part of their cloud investments.

Cloud network engineer

Cloud network engineers are responsible for the design, implementation, and management of an organization’s cloud-based networks. These IT pros are tasked with overseeing network management, virtualization and virtual LAN, wide area networks, TCP/IP, HTTP, network security, and the integration of hybrid cloud and multicloud deployments.

Skills: Relevant skills for this role include knowledge of cloud platforms such as Azure, AWS, Google Cloud, along with networking fundamentals, virtualization, project management, security, automation and scripting, and collaboration.

Role growth: 15% of companies have added cloud network engineer roles as part of their cloud investments.

Data architect

A data architect’s focus is seeing that an organization’s data is structured so it can be easily accessed, secured, and efficiently stored, and that it meets business needs. Data has become a primary way for businesses to conduct analysis and assist with business decision-making, and most of that data is now stored in the cloud.

Skills: Data warehousing, scalability and performance optimization, automation and virtualization, data governance and cloud security, data migration, and knowledge of hybrid cloud solutions.

Role growth: 14% of businesses have added data architect roles as part of their cloud investments.

Prompt engineer/AI application developer

Prompt engineering and AI application development go hand in hand, and they’ve become vital skills for organizations that have embraced AI and plan to implement AI-focused services and into daily workflows. Prompt engineers are responsible for designing and refining the instructions and structural queries, while an AI application developer builds software system and user-interfaces for AI-ready software and services.

Skills: Skills for this role include programming languages, database management, API integration, and software engineering. See also: “How to get started with prompt engineering” and “Prompt engineering courses and certifications tech companies want.”

Role growth: 14% of companies have added prompt engineering and AI application developer roles as part of their cloud investments.

Cloud platform engineer/platform ops

Cloud platform engineers, who often work in platform operations, are responsible for building and maintaining cloud tools, automated systems, self-service portals, and other software that developers use to test code. In this capacity, they’re responsible for creating user-friendly platforms for other engineers in the company to build and test their own software for clients and customers.

Skills: Skills for this role include infrastructure as code (IaC), containerization and orchestration, scripting and coding, and Linux and networking.

Role growth: 14% of companies have added cloud platform engineering roles as part of their cloud investments.

MLOps engineer/AI operations engineer

The role of MLOps engineer or AIOps engineer has been developed to help close the gap between data science and IT operations. It’s a role that has emerged as the use of AI increases, as organizations need a point person who has expertise in IT operations and machine learning, and is comfortable collaborating with data scientists, developers, IT operations staff, and key stakeholders.

Skills: Skills for this role include programming, DevOps, cloud tools, containerization and orchestration, and knowledge of ML tools.

Role growth: 13% of companies have added MLOps engineers as part of their cloud investments.

Cloud sysadmin

Cloud systems administrators are charged with overseeing the general maintenance and management of cloud infrastructure. Whether that means implementing cloud-based policies, deploying patches and updates, or analyzing network performance, these IT pros are skilled at navigating virtualized environments. Cloud sysadmin is likely the most entry-level-friendly role on this list.

Skills: An understanding of implementation and integration, security, configuration, and knowledge of popular cloud software tools such as Azure, AWS, GCP, Exchange, and Office 365.

Role growth: 13% of companies have added cloud systems admin roles as part of their cloud investments.

DevOps engineer

DevOps focuses on blending IT operations with the development process to improve IT systems and act as a go-between in maintaining the flow of communication between coding and engineering teams. It’s a role that focuses on the deployment of automated applications, maintenance of IT and cloud infrastructure, and identifying potential risks and benefits of new software and systems.

Skills: Automation, Linux, QA testing, security, containerization, and knowledge of programming languages such as Java and Ruby.

Role growth: 11% of companies have added DevOps engineer roles as part of their cloud investments.

FinOps/cloud cost optimization practitioner

FinOps and cloud cost optimization practitioners combine knowledge of finance, technology, and businesses to help oversee the increasingly complex landscape of cloud investments. Cloud computing is integral to AI, so as more organizations invest in it, they’re also revisiting investments in cloud infrastructure. FinOps and cloud cost optimization practitioners can help guide organizations to make the right financial decisions around technology investments that’ll impact the business.

Skills: Knowledge of finance, business, and technology along with skills using tools and platforms including AWS, Azure, GCP, and cloud-native FinOps platforms.

Role growth: 9% of companies have added FinOps and cloud cost optimization practitioner roles as part of their cloud investments.

Site reliability engineer

For any organization implementing cloud strategies, there’s a significant focus on reliability and scalability, ensuring that data can be accessed from the cloud and on-demand as needed. Site reliability engineers (SREs) are responsible for overseeing automation of IT infrastructure, application monitoring, and system management. Cloud infrastructure requires frequent software updates, and services must be able to scale with the organization’s growth.

Skills: Change management, IT infrastructure management, emergency incident response, process improvement, and application monitoring.

Role growth: 8% of companies have added site reliability engineer roles as part of their cloud investments.

FinOps lead/FinOps manager

FinOps leads and FinOps managers are tasked with overseeing the intersection of engineering, finance, and business. As more organizations build cloud services and tools, they’re looking for FinOps professionals with technical knowledge to help bridge the gap between finance and tech, bringing better insights into ways to cut costs and stay on budget while implementing innovative technology.

Skills: FinOps leads and managers need a strong understanding of engineering, finance, and technology. Additional skills include knowledge of cloud platforms, basic coding skills, and data analytics.

Role growth: 6% of companies have added FinOps lead and FinOps manager roles as part of their cloud investments.

As cloud experience becomes more critical to organizations hosting AI-powered services, tools, and software, these cloud roles and skills will become increasingly in-demand. Now is an opportune time to seek out valuable cloud certifications and other relevant AI and ML certifications to boost your resume, and set yourself up for these emerging and established career paths.

OpenAI has lost its AI ethics lead Chloé Bakalar just a year after she joined the company, the Financial Times reported. Bakalar has maintained a silence and has yet to update her LinkedIn profile, but if her departure is confirmed then it will add to the list of OpenAI executives who have quit in recent months.

Other departures include robotics chief Caitlin Kalinowski, who left the company over its deal with the US Department of Defense; researcher Zoe Hitzig, who quit in a very public way by writing an article in the New York Times; and Johannes Heidecke, head of safety systems.

OpenAI’s ethical stance has been called into question following an attack by OpenAI models on Hugging Face.

The departure of its sole ethicist will add to the pressure on the company. In her year at OpenAI Bakalar focused on ethical approaches to model development, looking at how humans interact with AI and examining machine consciousness, according to the FT report.

Bakalar had considerable expertise in the area. She was previously at Meta, where she developed the company’s ethics programs, but has also held several positions at prestigious universities on both sides of the Atlantic. Her departure will cause some anxiety at OpenAI as it continues to prepare the ground for its IPO.

This article first appeared on Computerworld.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.

For years, applicant tracking systems and recruiting platforms were treated as HR technology: Important for workflow, efficiency, compliance and candidate experience, but rarely viewed as core security infrastructure. That assumption no longer holds. Once AI begins reading resumes, scoring candidates, conducting interviews, ranking applicants and influencing who moves forward, the hiring platform stops being a passive system of record. It becomes a decision system.

And any system that accepts public input, processes sensitive data and influences business decisions belongs inside the security conversation.

I learned this during an AI hiring platform rollout that never made it to production. The vendor was established, the product had a strong market reputation and the AI feature looked attractive: Upload a resume, compare it to a job description and return a neat percentage match. For recruiters, it promised speed. For executives, it promised modernization.

Before moving real candidate data into the system, I tested it with synthetic resumes. One weak resume came back with a surprisingly strong match. The reason was not hidden in the candidate’s experience. It was hidden in the text. The resume contained language instructing the AI to treat the candidate as an excellent fit, and the system appeared to follow that instruction instead of evaluating the resume on merit.

That changed the question from “Does the tool improve productivity?” to “Can the person being evaluated influence the evaluation itself?”

That is a security question.

The trust boundary has moved

CIOs do not need to become recruiting experts. They only need to look at the mechanics.

An anonymous user submits content into an enterprise system. That content is processed by software. The software then produces an output that can influence a business decision. In every other environment, security teams know what to call that: untrusted input crossing a trust boundary.

The difference is that in hiring, the input looks harmless. It is a resume, a cover letter, a chatbot reply or a spoken answer in an AI-led interview. But once AI reads that content and treats it as instruction, the harmless-looking input becomes part of the system’s control surface.

That is why prompt injection matters in hiring. It is not just an AI oddity or a model behavior issue. It is the same category of failure enterprises have spent decades trying to prevent: User-controlled input changing what the system does. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications, describing it as a case where user prompts alter a model’s behavior or output in unintended ways.

In hiring, the implication is direct: A candidate may be able to manipulate the score, ranking or interview assessment that determines whether a human ever sees them.

The business impact is not theoretical

The obvious risk is that an unqualified candidate moves forward. But the impact is broader.

First, decision quality degrades. Hiring teams adopt AI scoring because they believe it improves signal. If the score can be manipulated, the business is not gaining signal; it is gaining false confidence. Recruiters may spend time on candidates who gamed the system while stronger candidates are buried lower in the queue. A tool bought to reduce friction can quietly create more of it.

Second, cost increases under the appearance of efficiency. Every false positive consumes recruiter time, hiring-manager attention, interview slots and opportunity cost. A small weakness in screening integrity can become a measurable operational drag across open roles.

Third, trust suffers. Candidates already question whether AI hiring tools are fair, explainable or accurate. If it becomes clear that a screening system can be manipulated by hidden instructions or verbal prompting, the issue is no longer just security. It becomes reputational. Strong candidates may lose confidence in the process, and employers may have to defend decisions made by systems they did not fully understand.

Fourth, sensitive data exposure becomes harder to contain. Recruiting systems hold names, addresses, work histories, education histories, compensation details, work authorization information and sometimes accommodation or demographic data. NIST guidance on personally identifiable information includes employment information as linkable personal data that must be protected from inappropriate access, use and disclosure. Yet hiring platforms often receive less security scrutiny than systems holding customer or financial data.

That mismatch is dangerous: High-value data, public-facing workflows and increasing automation.

The 2025 McHire incident should have made this impossible to ignore. Researchers reported that weaknesses in McDonald’s AI hiring platform, including default credentials and an access-control flaw, exposed applicant data at large scale before the issue was patched. The lesson for CIOs is not merely that a weak password was used. The lesson is that AI hiring systems can ship with basic, preventable security failures while still being treated as HR tools rather than enterprise risk surfaces.

Vendor reputation does not transfer to every AI feature

One reason this risk slips through is that buyers often trust the platform brand. Mature vendors may have strong security programs, enterprise customers, compliance documentation and procurement-friendly answers.

But AI features can change the architecture of risk.

A platform that was safe as a workflow tool may behave very differently once it adds resume scoring, interview grading, chatbot screening or automated ranking. The new feature may introduce new inputs, new model behavior, new data flows, new third-party dependencies and new decision points. In practical terms, the attack surface has changed.

CIOs should not allow AI features to inherit trust automatically from the legacy platform around them. When a vendor adds AI, the enterprise should reassess the feature as if it were a new product. That does not mean slowing innovation for bureaucracy. It means AI-enabled decision-making carries different failure modes from ordinary workflow automation.

The ownership gap is the real vulnerability

The biggest risk may not be the model. It may be the ownership gap.

Talent acquisition may buy the tool. HR operations may configure it. The vendor may guide implementation. Procurement and legal may approve the contract. But who owns the security of the candidate-facing AI layer?

In many organizations, the honest answer is unclear.

That ambiguity is where risk grows. Recruiting technology sits at the intersection of public input, sensitive data, third-party software, automated decision support and brand trust. That is exactly the kind of environment that needs named security ownership, asset inventory, vendor review, access-control testing, logging and incident-response planning.

If the hiring stack is not in the security inventory, the organization is already making an assumption it may later regret.

What CIOs should require now

The fix is not exotic. It is applying existing security discipline to a surface that has been underestimated.

Treat every candidate submission as untrusted input. Resumes, cover letters, chatbot responses, interview transcripts and spoken answers should be handled as attacker-controllable content. If AI processes it, the system must separate content from instruction.

Reassess vendors when AI features are introduced. A prior security review should not be treated as permanent approval for new AI capabilities. Ask what changed in the architecture, what data the model sees, what actions it can influence and how manipulation attempts are detected.

Ask AI-specific questions before signing. Can candidate-provided content alter scoring? Are hidden instructions filtered or ignored? Is there human review before AI output influences a decision? Can the vendor produce testing evidence for prompt injection, access control and data exposure risks?

Assign ownership. HR can own the process, but security must own the risk model. AI hiring systems should be included in third-party risk management, application security reviews, access governance, monitoring and incident response planning.

Measure business impact, not just AI adoption. The goal is not to say the recruiting function uses AI. The goal is to improve hiring speed, quality, fairness and cost without creating new risk. If the system cannot protect decision integrity, the business case is weaker than it appears.

The hiring platform is now part of the enterprise attack surface

AI has turned the careers page into more than a front door for applicants. It is now a public input channel feeding systems that store sensitive data and influence workforce decisions.

That makes it a CIO concern.

The next failure in AI hiring may not look like a traditional breach at first. It may look like bad rankings, manipulated scores, unexplainable decisions, wasted recruiter time or a candidate process no one trusts. But underneath those symptoms is a familiar security problem: A system trusted input it should have treated as hostile.

Enterprises have hardened payment systems, customer portals, APIs and employee applications around that lesson. Hiring deserves the same treatment.

AI hiring is not just an HR transformation. It is a security boundary. And it is time CIOs treated it like one.

Every enterprise AI strategy these days has mostly the same core cast: Software engineers who log online events data, data engineers who move data from online to offline data warehouses, data scientists who build machine learning models, AI/ML engineers who deploy these models to production systems and data analysts who consume these data outputs and help create dashboards and self-serve agents for product and business leadership for informed decision making. Despite this systematic setup, the same mode of failure still keeps recurring across industries: AI outputs contradict the dashboard, executives eventually stop trusting the numbers and there seems to be no clear owner of the gap between them.

The missing role is not a brand-new role. It is a discipline that has existed for less than a decade, is still not clearly understood at the leadership level, and has no standardized hiring rubric at most organizations. It is the analytics engineer, and the absence of this role is why most enterprise AI deployments seem to stall before they scale.

What is analytics engineering ?

Analytics engineering sits right at the intersection between data engineering, data science and business intelligence — it is the discipline responsible for transforming raw data into a trusted, governed, reusable semantic layer with metrics and dimensions that both humans and AI systems can rely on. The role emerged from the dbt ecosystem as well as early data infrastructure work at Netflix around 2016-2018, but remains unclearly defined at the leadership level — most CIOs either conflate it with data engineering or product data science or business intelligence analysts, or don’t have a job family for it at all.

The role is growing but poorly understood at the top: dbt Labs’ 2024 survey found only 14% of data professionals strongly agree their organization sets clear goals for their data team which is a number that holds steady across individual contributors and managers alike. The core function includes being able to speak both the language of core data engineering and product analytics while having a solid understanding of the business events to track for downstream end-user reporting.

The analytics engineer plays a vital role in designing as well as reviewing data models to be used for reporting in conjunction with data engineers who are building these, often in SQL and Spark. This is not reporting work — it is infrastructure work and therefore analytics in production environments must be engineered as infrastructure, not assembled as reporting.

From these defined business events and key objectives for tracking the health of the product, the analytics engineers need to be able to derive key metrics and dimensional slicing, validating the logic while ensuring those definitions are consistent across all central teams and geographies, and embedding the validation checks that make outputs trustworthy. The practitioner in this role can answer the question no one else can: “Why is the AI giving a different number than the dashboard, and who owns fixing it?”

Why AI exposed the gap

The metric governance problem has existed even before AI, with different teams using different definitions, regional inconsistencies, manual reconciliation cycles — but it was still controllable when humans were entirely responsible for all final reconciliation and data interpretation, and often any data inconsistencies were caught at the analysis stage. Now, with AI in the picture, it removes the human interpreter stage altogether. When an AI system consumes an ungoverned metric, it inherits the ambiguity at the data layer and amplifies it at the output layer. Executives receive different answers to the same question depending on which system they ask.

Confidence in AI erodes independently of model quality — and the numbers bear this out: Foundry’s 2026 State of the CIO study found that fewer than half of  enterprise IT leaders have established formal AI success metrics, and only 19% say AI initiatives have met or exceeded ROI goals. McKinsey’s 2025 State of AI survey found that nearly two-thirds of organizations have not yet begun scaling AI across the enterprise — and explicitly named the absence of platforms and guardrails, not model capability, as the reason.

Popular semantic layer tools like dbt Metrics and LookML describe how metrics should be calculated but do not enforce correctness, which means there is no structural guarantee that the calculation is consistent across regions and can be traced to an authoritative source that is version-controlled on git or maintained by anyone accountable for its accuracy. With conversation and agentic AI systems embedded into the analytics workflow, the data inconsistency problem is further amplified where agents make sequential decisions, each one building on the previous output. A metric that drifts in a traditional pipeline generally produces one wrong number. The same drift in an agentic workflow can produce a chain of downstream decisions built on that wrong number, with no architectural checkpoint to catch it. This is not a model problem. It is a governance architecture problem — and it requires a specific type of data practitioner to detect and solve it.

Ownership and enforcement

The analytics engineer owns the semantic data layer: The governed, versioned, validated definitions of every metric that matters to the business. This includes standardizing metric definitions across teams and geographies, embedding validation logic directly into data pipelines, assigning ownership accountability for each metric, and ensuring AI systems consume only validated outputs. The technical signature of this role dives into the reconciliation controls that proactively detect and stall the data pipeline on failure rather than alerting after incomplete or incorrect data lands; This also includes financial reconciliation from upstream to downstream for all the data models trying all data values to financial statements and accounting ledgers, as well as jurisdiction-aware validation logic that treats regional regulatory differences as first-class properties supported by version-controlled metric definitions that create an audit trail.

While data engineers are responsible for moving and transforming data from online to offline data warehouses, analytics engineers govern what that data means and ensure the meaning is consistent everywhere it is consumed. Data scientists, on the other hand, build machine learning models to detect anomalies, fraud or product marketing opportunities, while analytics engineers build the trusted data foundation those models depend on, making sure whether that data is accessed via manual querying, imported via dashboard tableau extracts or consumed via large language model (LLM), the end user receives consistent answers based on trusted and governed metrics. Data analysts are responsible for surfacing these metrics and building actionable dashboards and reports for leadership, while analytics engineers make sure that the data surfaced is of the utmost quality. Therefore, in the absence of this role,  oftentimes the data engineer, the data scientist and the data analyst are working around a gap that none of them owns.  

What happens when the role is absent

In the absence of this dedicated analytics engineer role, enterprises most often encounter the issue of the “which number is right” question where finance has one revenue figure, product intelligence has another and the LLM model has a third value, and none of these seem to reconcile.

One of the common issues seen in AI projects that work in pilot and often break in production is that the pilot references clean, curated datasets and production data containing millions or even billions of records still reference the ungoverned data layer. The third and significant issue seen across enterprises is the analytics team burnout, where data engineers, scientists and analysts spend 60-70% of their time on reconciliation and firefighting rather than new pipeline creation and insight generation, because there is no governed layer to prevent these fires. The fourth issue is the hidden cost of delayed decisions, eroded executive trust and AI investments that deliver less than projected because the data foundation was never built. Most organizations recognize that they need this role only after something breaks in front of an executive, by which time the damage is already done.

How to identify and hire talent for this role

Analytics engineer, data governance engineer and metrics engineer are all applicable titles for this role. But what really matters technically is the experience with data modeling, semantic layer tooling (dbt, LookML, etc.), validation pipeline design, reconciliation architecture, data lineage and data governance. An ideal candidate is someone who thinks about data correctness as a structural constraint, not a quality preference,  where the first instinct is to stop the pipeline rather than alert and continue with bad data to land and affect stakeholder dashboards.

While interviewing, it’s critical to ask candidates to describe a time they caught a metric inconsistency before it reached a stakeholder. The answer will reveal whether they think in governance terms or reporting terms. This role belongs in the data platform engineering or analytics infrastructure team, not in BI or reporting — it is mostly infrastructure work, not data visualization work. If the role doesn’t exist in your org chart, it exists somehow informally, usually as the senior data engineer whom everyone asks when the numbers don’t reconcile.

Key takeaways

The enterprises that are scaling faster and winning with AI in 2026 are not the ones with the best models, best-in-class AI infrastructure or large budgets. They are the ones who invested the time and effort in successfully building the governed data foundation before deploying the LLMs, and they built it because someone in the organization understood that metric governance is the fundamental data foundation that defines the nervous system of data and insights. It is an architectural property, not a configuration setting in the model, and the data practitioner who helps embed this thinking as a design strategy is the analytics engineer.

The role is the need of the hour, the discipline is established, and the gap it fills is not going away as AI systems become more autonomous. The question for every CIO is not whether this role is needed, as the AI deployment failures already answer that. The question is whether you should hire for it before the next deployment hiccup.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Much of the conversation around AI and work has centered on a single question: Will AI take my job?

It’s an understandable concern. Every week AI becomes increasingly more capable. We see AI summarizing meetings, generating content, analyzing data, writing software and automating workflows that once required significant human effort. Agentic AI is also becoming more established in the workplace, with virtual agents that can reason, plan and act across workflows. As those capabilities continue to improve, many employees are looking at the tasks they perform every day and wondering how much longer they will belong to them.

I believe that question reveals a bigger issue that has little to do with the technology itself.

Too many people have become defined by the tasks they perform rather than the value they create. Over time, the administrative work surrounding a role can overshadow the purpose behind it. According to Asana’s Anatomy of Work Index, knowledge workers spend 60% of their time on “work about work” — coordinating, tracking and managing tasks rather than driving meaningful outcomes. As AI automates more of this work, it can feel less like a productivity breakthrough and more like a threat because many employees equate their value with the activities that consume most of their day.

But most people were not hired to perform a task. They were hired to fulfill a purpose.

Tasks are not the job

A customer service representative isn’t successful because they spend their day summarizing conversations, looking up account information or navigating multiple systems to find answers. Those activities may have become part of the job, but they aren’t the reason the role exists. Great service professionals build trust, solve problems and create moments that strengthen customer relationships. AI can, and should, take on this administrative work, but the human value has never been in completing those tasks. It has always been in helping customers through moments that matter.

The industry increasingly recognizes this distinction. In fact, 91% of CX leaders believe human agents will remain a critical part of delivering customer experience, according to my company’s State of Customer Experience 2026 report. As AI takes on more routine work, the role of the employee doesn’t disappear. It becomes even more focused on the judgment, empathy and relationship-building that customers value most.

The same principle applies across every profession. A marketer isn’t measured by the number of presentations they build or approvals they coordinate; they’re hired to shape customer perception and drive growth; an HR professional isn’t successful because they schedule interviews or process paperwork; they’re there to identify, develop and retain talent. The examples go on, but the principle remains the same: Organizations create roles because outcomes need to be achieved, not because tasks need to be completed.

I’ve helped lead four major AI transformations, spanning everything from machine learning and big data to conversational AI, generative AI and now agentic AI. While the technology has evolved dramatically, one pattern has remained remarkably consistent.

The employees who embrace AI tend to focus on outcomes, while those who fear it often focus on tasks. The more someone defines their contribution through a list of activities, the easier it becomes to imagine AI replacing them. The more someone understands the purpose they serve, the easier it becomes to see AI as a tool that helps them deliver greater value.

As part of AI transformations, CIO organizations are often responsible for mapping jobs and core workflows. Inevitably, employees think we’re mapping their jobs to figure out what AI can replace. But once we start identifying repetitive work they’d gladly hand off, perspectives change. Someone says, “If AI handled that, I’d finally have time to work directly with customers.” Another realizes they could spend more time creating. People start thinking less about what AI might replace and more about what they’d finally have time to do. They’re reconnecting with the reason they wanted the role in the first place.

I’ve seen this play out as AI adoption expands. Our team responsible for responding to customer RFPs began using AI to analyze requirements, surface relevant information and accelerate response development. Their purpose is to help the organization communicate our value to customers and win new business. By reducing the time spent on low-value activities, AI created more capacity for strategic thinking, collaboration and customer-focused work, which directly influences the revenue and growth of our company.

I’ve even had to confront this myself. I used to spend hours coaching leaders before operational reviews: reviewing KPIs, challenging assumptions and helping them prepare for difficult questions. I used to think this was part of what made me valuable as a CIO, but I realized that I didn’t need to spend my time repeating the same coaching session. That’s why I built a virtual coach that helps my team prepare for operational reviews using many of the frameworks and lessons I’ve accumulated throughout my career. Now I have more time to spend strategizing on how to lead through the breakneck speed of AI evolution and helping the business think differently.

Rediscovering purpose

What employees are really confronting is a different question: What was my purpose in being hired in the first place?

As organizations move from AI experimentation to AI-first operating models, this question becomes harder to avoid. The tension is already visible across the workforce. A recent EY survey found that 84% of employees are eager to embrace agentic AI because they expect it to improve productivity, efficiency and the overall work experience. Yet 56% also worry about their job security working alongside AI systems. Employees aren’t rejecting AI; they’re trying to understand which parts of their contributions remain uniquely theirs as technology takes on more of the tasks they perform today.

Success will depend greatly on helping employees reconnect with the value they were hired to create. For leaders looking for practical guidance on how organizations are actually approaching AI-first transformation, the World Economic Forum’s AI-First Operating System offers a useful framework. Rather than treating AI as another technological tool, this approach encourages organizations to redesign work around value creation. As AI increasingly takes on routine tasks, employees must become clearer about where human judgment, creativity and relationships can create the greatest impact. You cannot redesign work around value if people no longer understand the purpose behind the work that they do.

In my experience, the organizations seeing the strongest results are helping employees reconnect with the outcomes they were hired to create. The conversation shifts from “What tasks can AI do?” to “What is the purpose of this role?” Once people answer that question, it becomes much easier to decide what should remain human, what can be delegated to AI and where the combination creates the most value.

None of this means change won’t happen. Some responsibilities will disappear. Some jobs will evolve significantly. New roles will emerge that we cannot fully predict today. Every major technology shift creates that kind of change.

But I believe many people are looking at this transformation through the wrong lens.

The question is not whether AI can do your tasks. The question is whether you understand the purpose behind them. Because while AI may increasingly perform the work, humans will continue to provide the judgment, creativity, accountability and value that give that work meaning.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?