Reining in AI for Banking and Legal Industry Events

"No one wants to be an early adopter of this tech," says Eventogy founder and CEO Cem Kocu, with respect to AI agents and event-data analysis. His take doesn't sound like the all-in-on-AI hyper-enthusiasm we've grown accustomed to hearing in the event tech space, but his caution is motivated by that of the company's clients. Eighty-percent of clients they serve are in the financial and legal sectors. Eventogy provides an enterprise event management platform specifically for those in highly regulated fields.

"Any time there's some new technology mounting, we're seeing our clients are apprehensive," says Kocu. "They're hesitant about adopting any new technologies.

"We've noticed huge amounts of restriction around the AI models that our clients are allowed to use internally," Kocu continues, "so we're really happy that we stood by the concept of no AI for AI's sake. That would have been a step backwards for us if we'd built in more AI and had to modify it after the fact."

Still, Eventogy's engineers have no shortage of ideas and roadmaps that could include AI functionality. How do you balance the drive for innovation with the utmost need for caution and security? I sat down with Kocu to discuss the approach his company is taking and how his clients are able to get the benefits of AI without ceding any of the control.

Would you say your clients are resistant to AI use?

Primarily, they just want to maintain control. I actually come from corporate banking myself. It's part of the reason I have some intimate knowledge of how their systems work, not just in terms of technology, but also workflow processes. And once once you've established how one works, they all pretty much follow the same model.

Adding AI in for the sake of it is also a complication barrier, which corporate banks don't want. It's an added risk. And it's an added audit component, as well as creating additional significant work for my CTO, who is currently drowning in security questionnaires that we get daily from our clients. Plus, it's an added cost base for our clients in terms of their added security requirements. So we want to keep things as pure as possible and provide value where we see it fitting.

How do you provide the right amount of functionality and restrictions across those different requirements?

We're putting the burden of that back onto their technology teams. Rather than providing them with our own AI, we're giving them full access to Eventogy through MCPs [connectors of different systems], and we're allowing them to use their own AI models, whatever that might be.

Eventogy is agnostic of that technology, whether it's Gemini, whether it's Claude, whatever it might be. All it requires is us to align ourselves with our clients' security requirements. So it allows our clients to completely control and manage a whole number of things that they wouldn't be able to do if we provided them just classic AI.

There have been documented instances of AI inventing numbers when the desired data is missing. How do you address the potential of those issues?

Great question. We're talking about the hallucination paradox that provides people with answers to truthful questions, which have been made up mostly because there are missing gaps in the data. The way we're approaching this is that Eventogy doesn't use memory at all. Rather, each query from the client is just a direct question to our database. It doesn't store the information to the memory. It simply queries the database every single time. We're not asking agents to think; we're asking agents to fetch.

Does that guarantee data won't be invented, by simply asking agents to fetch?

Fetching doesn't make a made-up answer impossible, and I'd be wary of anyone who says it does. What it does is move the risk to a place where it can be checked.

When a planner asks her assistant “how many guests registered for the partner breakfast?,” the assistant doesn't answer from memory. It asks Eventogy, which hands back the relevant data straight from the event record. The assistant then forms its answer from that data.

So the facts come from the record, but the answer is still written by the AI, and that's where it can go wrong: it can ask for the wrong data, misread what comes back, or slip when it counts or calculates. That's why every lookup is recorded, so anyone can see exactly what Eventogy handed over and check the answer against it. And the connection is read-only, so a wrong answer can never change the record.

For the numbers that matter, spot-check. We just make the check possible.

Maintaining that balance between AI productivity and manual oversight sounds like a challenge.

It can be, but there is apprehension in both directions. It isn't just about the cost of using AI and the associated potential dangers, it's also become “what's the cost of not using AI and being left behind?” So we have to walk that fine line and provide solutions that align with our clients' fears, but also supercharge the potential with AI for what they want to accomplish.

Right now we're doing read-only interactions. The next step will be to let AI write, and that's ready internally. We've built that, but we're not ready to launch it yet because we're assessing client appetites as to whether this is something that they're going to be comfortable with.

What are some examples of that AI write functionality?

The commands are simple. "How many people have registered for this event, and how many people have not yet responded?" Seventeen haven't responded. "OK, build me an email that sends those 17 people an invitation and a reminder. Show me what that looks like. Send now." That's a write action. Or something as grandiose as "build me an event that mimics last year's AGM 2025 event, but change the location to X."

That tech is ready, and we'll have guardrails in place to prevent AI from going rogue and doing its own thing. But we want to work very slowly and make sure that we are working at the pace of our clients.