Plone-based software has been used for this, for example fbi.gov and similar law enforcement agencies. You can easily create content types that store the information you want to retain and search for the different types of records. Data entry, edit and display forms are built in. Permissions allow you to control who can add, edit, and view different records. Built in search will work but you can customize it to do more advanced things. There is a nice API you can use to connect Plone content with other systems.
I don't understand why you feel the need to reject Plone entirely because it doesn't do everything out of the box. It does the most important part.
As a start, the things you need are a place to enter and store the information. You can then connect Plone or enhance Plone to add the abilities it does not have built-in. There is a lot of ML you could use to classify imagery and video, there is a REST API to connect Plone to those.
I'm not going to solve this person's business problem here, but if they want more precise advice they can ask for it or they can hire anyone of the many Plone agencies who'd be willing to help them figure out a complete solution.
Plone is a CMS so it's best usecase as a framework is people editing content and publishing it.
If all you want is an database backed application with not CMS parts then the pros and cons might go against using a CMS for this purpose. However you have the following options
Plone Volto makes it easy to integrate any backend app with an api so you could combine a nice CMS with an app build in anything on the backend and react (using volto framework) on the frontend. The app doesn't have to use the zodb database.
Plone Headless makes it easy to make a more custom app in any frontend framework that combines Volto or Classic as your admin UI for the CMS parts and any other backend for the app parts.
If you do want to using the plone DB there are options
We built https://www.swimmingpoolregister.nsw.gov.au/ using Plomino on top of plone which is a somewhat similar usecase of collecting data and having thousands of internal users use it as a case management type system on the backend. It's kind of like a low code system plugin for plone. But I'm not sure I'd recommend this approach, esp as it's not upgraded to python 3 or plone 6, and also because its using the zodb in a more relational way and it's not really well suited for that.
You can try to use content types. I don't really recommend this either. even if somethings about it make it fast, you eventually find aspects of content types don't fit the database usecase well and you end up fighting the framework. And you still have the issue of ZODB as a relational database.
You can build an app in zope either with a restapi and some frontend or the classic way. But again, what part of the framework are you getting benifit from? if you know zope then great. But if you want something others are more likely to know then there are more popular choices
Something that gets missing in a lot of these discussions is that framework choice should be more about what you know or what you can hire for, now and in the future. and less about speed or DX (how nice it is for developers) of the framework.
Seriously, you don't want to build an application in the scope of law enforcement based on (backend) technology that we should consider in general a technical debt and in many ways outdated. Both the ZODB and our "enterprise search engine" portal catalog are technical debt. A serious decision maker would reject such project proposal. On top of that, we have many tinkered integration stories to other system. This may work for our CMS solutions where we only have a niche market, but not for law enforcement. Let's get serious and realistic. Regarding the "many Plone agencies"...larger and capable agencies...perhaps 2 to 3...and the few freelancers don't count as agencies are a legally not able to offer such contracts to official authorities.