AI: A More Complete IT & InfoSec Story

Maria Haight Global Information Security Officer at Joyson Safety Systems

When organizations talk about AI, the conversation usually starts with the model: the exciting use cases and how fast something can be deployed. At the Innovate Cybersecurity Summit, Maria Haight, Global Information Security Officer at Joyson Safety Systems, argued that the model is only one chapter. A former CIO and CISO, she focused on what IT and security leaders need to do after the AI governance board approves yet another initiative.

Her talk was packed with action items, which was deliberate. She wanted attendees to leave with something they could put in place back at the office later that week.

A Consistent Front Door

Requests to use AI tools arrive from everywhere: through IT, through procurement, or from a business unit with a great idea. There must be a consistent entry point, whether that is a formal governance board or a simple online form. A live poll of the audience showed that many organizations are still closer to the “wild, wild west,” though she noted the answers would have looked different six months earlier. Maturity is coming quickly.

The first question, she said, shouldn’t be “can we buy or build this?” It should be “what business problem are we trying to solve, and is AI really the right answer?”

At her company, a small group does a technical and security sniff test before anything reaches the full governance board. It consists of the InfoSec lead, an IT lead, and the company’s AI champion. If a request has no data security around it, or duplicates a tool already in place, it doesn’t go forward, and the requester is told why. Requests that pass go to the full board, which brings in legal, HR, and compliance.

Keeping Proofs of Concept from Lingering

Many approved requests become proofs of concept, and a POC can linger indefinitely while its scope drifts from the original intent. Her remedy is to define the timeframe, the goal, and a measurable outcome up front, whether that is time saved, quality improved, or a financial gain. Licensing and cost belong in the POC too, so the team can agree whether to move forward or stop.

Assessment Beyond the One-Time Questionnaire

Risk shifts as AI moves from adoption to development to deployment. Adoption brings shadow AI, weak governance, and data leakage. Development brings insecure integrations, model configuration changes, and access control issues. Deployment brings injection attacks and malicious use. A single vendor questionnaire won’t capture all of that.

Her IT and InfoSec assessment covers:

• Model changes: what happens if the vendor swaps the model without notice. She said this is already happening.
• Training and access: how the solution is trained, and which systems and APIs it can reach.
• Hosting and identity: where it runs and how identity and access controls are applied.
• Scalability: a solution that works for 20 employees may behave very differently at 5,000.
• Accuracy in context: a small error is acceptable in an internal summary but not in a safety decision or a financial transaction.
• Support: who responds if the system fails, produces a harmful response, or exposes sensitive information.

Data: AI Exposes What Organizations Already Have

A weak data security practice will be exposed further by AI. In a second audience poll, most respondents landed in the middle: strong in some areas (HR, say) and weaker in others (such as intellectual property).

Her data checklist:

• Classification, whether public, internal, or confidential, should be in use and actually applied.
• Leaders should know whether prompts and outputs are retained, for how long, and what the model is trained on.
• Encryption is not the whole answer. If an agent is authorized to retrieve far more than the use case needs, data can still be exposed while in use. That is a leakage problem.

Data decisions also drive cost. Sending entire documents or large repositories to a model, rather than just the pieces needed, can become expensive under consumption pricing.

The Real Cost of AI

AI costs are layered. The license or model charge comes first, but APIs, cloud infrastructure, storage, additional log files, monitoring tools, and integration support follow.

Then there are tokens. A token is a unit of information the model processes, not necessarily a whole word, and punctuation, numbers, code, and different languages are all tokenized differently. Input costs include what employees type, system instructions, conversation history, uploaded documents, and security instructions. Output has its own rates, which vary by provider and contract.

She pointed to three drivers of cost growth:

1. Context growth. The application may resend earlier conversation to the model, so a short question can carry a large accumulated context.
2. Retrieval. RAG systems pull multiple document passages and send them to the model.
3. Agentic loops. Back-and-forth between prompts and data keeps consuming tokens.

True total cost of ownership also includes engineering time, retraining and maintenance, latency, monitoring, user training, scarce AI champions spread thin, support staff, legal, and compliance. Switching models means re-investing in work already done. She cited the line that the model itself is often less than 20% of total cost, with everything around it making up the other 80%. Her own experience this year was that token utilization far exceeded expectations, and heading into 2027 she sees AI becoming as much a financial conversation as a technology one.

Visibility: The AI Jungle

The talk cited statistics from Canopy (formerly NoCode), which she noted were already about nine months old. They suggested an enterprise may have between 5 and 30,000 AI applications in production, with 15% to 20% facing externally, and in some companies up to 50 new agents added per day on average. Her point was that organizations need visibility into all of it.

She also flagged forgotten agents that are no longer used but still sit in the environment. Someone has to deprecate and clean them up.

Her monitoring recommendations span four areas:

• Operational: performance, uptime, API usage, and storage.
• Security: inappropriate data uploads, excessive access, data leakage, unusual tool use, and agent changes.
• Financial: license utilization, token consumption, cost by use case, and unexpected increases, which could signal a model change or a project gone rogue.
• Business: accuracy, adoption, user satisfaction, and return on investment.

AI projects, she stressed, are not build-and-forget. Ongoing support needs shouldn’t land solely on IT, but they must be discussed upfront during business planning.

The Agent Catalog

Cataloging agents is, by her own admission, the hardest area right now. Her view is that an agent catalog should be the authoritative source for AI agent use. It should record:

• The business owner and the technical owner
• The model in use
• Data classification, such as whether PII or IP is permitted
• Permissions, meaning which groups may use the agent
• The operating environment, internal or external
• A unique identifier and version history, so the agent running today can be confirmed as the one that was assessed and approved
• Links to source code, change logs, and risk assessments
• Financial details, including the funding owner, the contract, and the renewal or review date

She suggested reviewing the catalog with the governance board at least quarterly, which is also where stagnant agents can be identified and shut down.

On how deep cataloging should go, down to individual executive-assistant agents, she wants visibility into all of them, but not through manual effort. She doesn’t want “another SharePoint with another spreadsheet that’s quickly outdated,” and is looking for tools that detect agents automatically, including who built them, the code source, who manages them, and what data they use.

Planning for When an Agent Goes Down

For critical agents, leaders need to decide what must be preserved and how the business continues if the solution is unavailable. If an AI agent on a production line fails, does anyone remember how to do the work by hand? Prompts, data and workflow backups, training data, and integration details need to be documented and backed up as part of BCP and DR processes, ideally with a manual fallback. Coming from a finance background, she recalled pulling out paper and writing logs until systems returned. In manufacturing, where a stopped line has immediate impact, the continuity plan must reflect business impact.

Three Questions for Leaders

The talk closed with three questions for every security and IT leader:

1. Does the organization know which AI systems and agents are operating across it?
2. Does the organization understand the complete cost, including token consumption, infrastructure, security, support, and people?
3. If a critical AI service stopped working tomorrow, does the organization know how the business would continue?

Sustainable AI adoption, she concluded, takes more than selecting a model. The organizations that treat it as a full lifecycle of governance, security, cost, and continuity will be the ones that capture its value.