Geert Vromman

The through-line

Across everything Geert Vromman publishes, one argument keeps returning: the hard part of AI is almost never the model. "De technologie is zelden het probleem. De voorbereiding bijna altijd." [8] He treats AI implementation as an exercise in transformation rather than installation, because organisations do not arrive at it empty-handed: "AI implementeren is zelden een greenfield-oefening. De meeste bedrijven starten niet vanaf nul. Ze hebben bestaande processen, teams, gewoontes, systemen en verantwoordelijkheden." [7] The consequence he draws is consistent, whether the subject is HR, legal work or company-wide tool use: define the problem, the process change and the ownership before the technology arrives.

The second strand, more recent in emphasis, is that as systems become more autonomous the question shifts from capability to control. He frames this as a design-time concern rather than a brake on innovation [4], and pairs it with a practical insistence on rules, data awareness and traceability at the level of ordinary daily tool use [9].

On starting with the problem, not the tool

The failure pattern he sees most often is organisations opening with a product decision: "We gaan Copilot implementeren", "We testen een AI-rekruteringstool", "We laten ChatGPT onze policies schrijven" [8]. Six months later the result is limited adoption, sceptical colleagues and a management team asking where the ROI is [8]. What is missing is the set of questions that belong before the tool: which problem are we solving, who suffers from it, what changes in the process, who is accountable for the output of the AI, and when is it good enough [8]. His conclusion is blunt about the category error involved: "AI in HR werkt niet als een plug-in. Het werkt pas wanneer je opnieuw nadenkt over hoe kennis, processen en mensen samenwerken." [8] He also notes that the mistake is not excessive speed, but the wrong starting point [8].

On change management and buy-in

Because most AI work lands on top of existing habits and responsibilities, he treats adoption as a people question first: technology alone does not suffice, support and buy-in are not a detail, and the way you bring people along often decides whether AI actually makes an impact [7]. This is the connective tissue between his critique of tool-first thinking and his interest in how work is organised; the redesign of "hoe kennis, processen en mensen samenwerken" [8] is the same problem viewed from the process side.

On the control problem

He argues that AI is still discussed mainly in terms of possibility: what the system can do, which tasks can be automated, how much time can be saved [4]. As systems become more autonomous, an equally important question arrives: how do we retain control [4]. His position is explicitly not a call to slow down. It is a call to think from the design stage about boundaries, oversight, traceability and the ability to intervene in time [4]. He regards this as having moved out of theory: the control problem is a concrete challenge for organisations that want to deploy AI reliably, and worth attention from anyone who wants to look beyond the impressive demo [4].

On rules, SOPs and where your data goes

He is candid that governance is unglamorous: "Het klinkt niet meteen sexy: spelregels, processen, SOPs, richtlijnen." But letting employees work with AI without minimum agreements is a real risk today [9]. The familiar version of the question concerns free use of tools such as ChatGPT, Gemini, Claude or Copilot: what may be pasted in, which data is sensitive, what happens with customer information, personal data, contracts, quotations or internal documents [9]. He then extends it to the harder, less visible case. Paid accounts on a CRM system, accounting package, design application, project management tool or HR platform now very likely include an AI assistant, an AI premium feature or a chatbot, and the relevant questions are whether you know which language model sits behind it, where the data goes, and whether it is stored, processed, used for training, shared with sub-processors or moved outside the EU [9].

On agents that absorb the back-and-forth

His worked example of useful automation is a intake problem rather than a generation problem. A lawyer drafting an employment contract first needs input from the client: sector, joint committee, working hours and schedules, specific arrangements, exceptions, context [10]. In many organisations that process is still largely manual, a meeting to request everything, then waiting on missing information, another email, a phone call, further clarification, and still something missing at the end, typically seven to ten contact moments before the file is complete [10]. The agent they built takes over that questioning, "Niet in juridisch jargon, maar in de taal van de klant" [10], asking the right questions in the right order and handing the lawyer a file only once all necessary information is available, which yields fewer incomplete files and less back-and-forth [10].

On making the first project easy to start

He actively points companies toward the funded on-ramp, noting that for Walloon companies wanting to move from an idea to a first concrete AI project, Start AI can subsidise 50% of the cost of a feasibility study or the development of a first working tool [6]. The invitation he issues is deliberately low-threshold and framed around an idea, a process to automate or a use case to explore [6]. The same breadth shows in the range of sectors he documents in CROPLAND's podcast conversations, from turning data into results in the food industry [11] to healthcare innovation [12] and AI use in the toy industry [13].

On the team

He writes about colleagues in terms of what they add rather than what they were hired for: curiosity, drive and the talent to turn complex AI challenges into practical solutions, which he says makes both the projects and the team stronger [3]. That framing, practical solutions over demonstrations, is the same standard he applies to client work [4][8]. He publicly welcomes new arrivals as people he looks forward to delivering AI projects with [1], and treats the internal podcast as a way of putting colleagues' own thinking into the open, whether on change management [7] or on the control problem [4].

On second lives for hardware

A smaller but firmly held position concerns discarded electronics. It has bothered him for some time that so much equipment is left over both professionally and privately: computers, phones and tablets are accounting-depreciated after three years or slightly too slow for specific applications, "maar daarom zijn ze nog lang niet waardeloos: ze kunnen perfect een tweede leven krijgen" [5]. He treats the first reuse project as a starting point rather than a gesture, since laptops come free every year and he intends to make it a standing habit [5]. Alongside this sits a two-year co-sponsorship of the SerSo Gravel Team, which he praises for two Belgian titles and four medals [2].

Takeaways

• Ask the questions that come before the tool: which problem, whose pain, what changes in the process, who owns the AI's output, and when is it good enough [8].
• Treat AI implementation as transformation, not installation, because existing processes, teams, habits and responsibilities are already in place [7].
• Design for control from the start through boundaries, oversight, traceability and the ability to intervene in time, without slowing innovation down [4].
• Audit the AI assistants embedded in tools you already pay for: know the underlying model, where the data goes, and whether it is stored, used for training, shared with sub-processors or sent outside the EU [9].
• Point agents at the intake bottleneck; replacing seven to ten contact moments of chasing missing information delivers complete files and less back-and-forth [10].
• Use available funding to de-risk a first step: Start AI can cover 50% of a feasibility study or a first working tool for Walloon companies [6].
• Depreciated hardware is not worthless hardware; make annual reuse of freed-up laptops a standing practice [5].