I can see why that could be considered a risk compared to using plain JDBC: to use JPA, you need a container or library that implements JPA, because JPA is not implemented in the standard JDK. You'd for example need to include Hibernate or some other implementation of JPA into your project.
However, in my opinion using JPA is still much better than using plain JDBC. With plain JDBC, you'll have to write a lot of low-level code by hand to convert from objects to SQL statements and back. In any non-trivial application, it will be much more work to use plain JDBC than JPA, and using JDBC will become a maintenance nightmare. Using JDBC vs using JPA is like programming in assembly language vs programming in a higher-level language.
Having to include external libraries, such as Hibernate, can be considered a risk - if there's a bug in Hibernate or whatever other JPA implementation you use, then that could affect your project. The more code and libraries you put into a project, the bigger the chance is that there's a bug somewhere that might affect the project. (But the risk is limited, and for example Hibernate is used by many thousands of companies around the world - if there would be some major bug in it, somebody most likely would have discovered it already).